| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: [zuul/zuul] 873832: DNM: Profile some dynamic layout operations https://review.opendev.org/c/zuul/zuul/+/873832 | 00:27 | |
| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: [zuul/zuul] 878945: Load configuration from unknown dynamic branches https://review.opendev.org/c/zuul/zuul/+/878945 | 00:32 | |
| -@gerrit:opendev.org- Zuul merged on behalf of Simon Westphahl: [zuul/nodepool] 887266: Don't reload config when file wasn't modified https://review.opendev.org/c/zuul/nodepool/+/887266 | 08:28 | |
| @dpawlik:matrix.org | Hello folks o/ I have small question. According to the doc: https://zuul-ci.org/docs/zuul/latest/config/job.html job execution order is: | 08:44 |
|---|---|---|
| parent pre-run playbook | ||
| child pre-run playbook | ||
| child playbook | ||
| child post-run playbook | ||
| parent post-run playbook | ||
| parent cleanup-run playbook | ||
| And all would be fine, but when child has a cleanup-run playbook, it is executed after parent post-run and parent cleanup-run playbook. Is it fine or it is a bug? | ||
| -@gerrit:opendev.org- Simon Westphahl proposed: [zuul/nodepool] 891667: Handle more quota errors during server creation https://review.opendev.org/c/zuul/nodepool/+/891667 | 09:32 | |
| -@gerrit:opendev.org- Simon Westphahl proposed: [zuul/nodepool] 891667: Handle more quota errors during server creation https://review.opendev.org/c/zuul/nodepool/+/891667 | 09:32 | |
| -@gerrit:opendev.org- Zuul merged on behalf of Simon Westphahl: [zuul/zuul] 891577: Use sorted list for index of deduplicated secrets https://review.opendev.org/c/zuul/zuul/+/891577 | 12:42 | |
| @dpawlik:matrix.org | > <@dpawlik:matrix.org> Hello folks o/ I have small question. According to the doc: https://zuul-ci.org/docs/zuul/latest/config/job.html job execution order is: | 13:56 |
| > | ||
| > parent pre-run playbook | ||
| > | ||
| > child pre-run playbook | ||
| > | ||
| > child playbook | ||
| > | ||
| > child post-run playbook | ||
| > | ||
| > parent post-run playbook | ||
| > | ||
| > parent cleanup-run playbook | ||
| > | ||
| > And all would be fine, but when child has a cleanup-run playbook, it is executed after parent post-run and parent cleanup-run playbook. Is it fine or it is a bug? | ||
| does someone know answer for that question ? | ||
| @dpawlik:matrix.org | sorry for ping :) | 13:57 |
| @harbott.osism.tech:regio.chat | well cleanup is to run after post, so that part is as expected. regarding the order of child cleanup vs. parent, I'm not sure, I would have expected the same order as for post-run, but maybe corvus can explain the difference | 14:31 |
| @jim:acmegating.com | the code looks like it should do the same for post, but the author of the feature did not add a test that includes inheritance and the docs are ambiguous, so, technically i guess the behavior is undefined. | 14:36 |
| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: [zuul/zuul] 887004: Add github event processing debug logs https://review.opendev.org/c/zuul/zuul/+/887004 | 14:50 | |
| @michael_kelly_anet:matrix.org | Couldn't find anything obvious, but is the commit hash of the change for a job available as an environment variable in some way? (I realize that I can grab it as an *ansible* variable, of course) | 17:45 |
| @michael_kelly_anet:matrix.org | In case it helps the question, I'm using the zuul-jobs golang-go job to run some tests which need to know the commit hash. Trying to avoid making the test depend on the massive library fanout of something like go-git *or* being able to run `git rev-parse HEAD` (because that's more fragile) | 17:59 |
| @michael_kelly_anet:matrix.org | But it's not obvious to me how I'd inject additional environment variables into it... | 17:59 |
| @clarkb:matrix.org | I think `{{ zuul.commit_id }}` has it. YOu can also look in the zuul.projects dict to get a full listing of all the incorporated git info. And you can look at the git state in the git repos for the job. Though the git state for the git repos in the job will by default be for the speculative state. If you look at the origin remote branch heads instead that will be upstream state and you can diff. Since zuul deals with speculative states what yo uhave in the job doesn't necessarily map to anything that exists in your code review system at that point in time | 18:00 |
| @clarkb:matrix.org | I think zuul.commit_id maps directly to the change/PR though without any speculative state. The projects dict and the content on disk in the git repos will be speculative state though | 18:00 |
| @michael_kelly_anet:matrix.org | Yea, that's the Ansible variable. I'm ok with the speculative commit hash, I just need a commit hash that's unique for what is being tested | 18:01 |
| @michael_kelly_anet:matrix.org | If I were writing the job myself, I'd just inject the ansible variable as an environment variable. I'm assuming it's not available as such by default? | 18:01 |
| @clarkb:matrix.org | https://docs.ansible.com/ansible/latest/playbook_guide/playbooks_environment.html | 18:02 |
| @clarkb:matrix.org | you can set it as part of the environment using ansible and the zuul variable | 18:02 |
| @michael_kelly_anet:matrix.org | Ok, sure. But that means I wouldn't be using the golang-go job from zuul-jobs. | 18:02 |
| @michael_kelly_anet:matrix.org | This is ok, just trying to determine if there's another alternative :) | 18:02 |
| @jim:acmegating.com | The structure of jobs in the zuul-jobs repo is intentionally designed around simple playbooks that are lists of roles, and the roles have all the logic. that's so that in situations like this, you just make your own playbook that's like 2 lines long with the extra whatever you need. in this case, an env variable. eg: https://opendev.org/zuul/zuul-jobs/src/branch/master/playbooks/go/run.yaml | 18:03 |
| @clarkb:matrix.org | I guess the other option is to add it to the library jobs assuming it is a thing golang commonly wants during builds | 18:12 |
| @clarkb:matrix.org | but no, our jobs haven't generally added that info in an env var. It is available in the ansible environment and you can inject it where necessary but as corvus says you ma need to write your own job or replace the run playbook in a child job or something | 18:12 |
| @jim:acmegating.com | i do not think it is appropriate to add to zuul-jobs. | 18:14 |
| @jim:acmegating.com | just inherit from the job, override the playbook and you're done. | 18:15 |
| @michael_kelly_anet:matrix.org | I agree with corvus , adding the env variable to the job in zuul-jobs is not what I'd want to do. | 18:42 |
| @michael_kelly_anet:matrix.org | The suggestion of just replacing the run.yaml seems totally sane though. It'll keep things simple. | 18:43 |
| @michael_kelly_anet:matrix.org | Thanks for the info corvus and Clark | 18:44 |
| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: [zuul/zuul] 891909: Remove unused github getBranchProtectionRule method https://review.opendev.org/c/zuul/zuul/+/891909 | 20:28 | |
| -@gerrit:opendev.org- Joshua Watt proposed: [zuul/nodepool] 891635: Add option to decline node request based on quota https://review.opendev.org/c/zuul/nodepool/+/891635 | 21:10 | |
| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: [zuul/zuul] 891910: Document max_threads_per_installation https://review.opendev.org/c/zuul/zuul/+/891910 | 21:12 | |
| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed on behalf of Tobias Henkel: [zuul/zuul] 761520: Only report dequeue if we have reported start https://review.opendev.org/c/zuul/zuul/+/761520 | 22:46 | |
| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed on behalf of Simon Westphahl: [zuul/zuul] 650276: Keep task stdout/stderr separate in result object https://review.opendev.org/c/zuul/zuul/+/650276 | 23:22 | |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!