| -@gerrit:opendev.org- Ian Wienand proposed: | 02:11 | |
| - [zuul/zuul] 858243: web: Even "better" hidden expandable content https://review.opendev.org/c/zuul/zuul/+/858243 | ||
| - [zuul/zuul] 858244: web: Differentiate console entries https://review.opendev.org/c/zuul/zuul/+/858244 | ||
| - [zuul/zuul] 858245: web: Show failed tasks with light red background https://review.opendev.org/c/zuul/zuul/+/858245 | ||
| - [zuul/zuul] 858246: web: Show failed tasks in red on task page https://review.opendev.org/c/zuul/zuul/+/858246 | ||
| - [zuul/zuul] 858247: web: Simply task status results https://review.opendev.org/c/zuul/zuul/+/858247 | ||
| -@gerrit:opendev.org- Ian Wienand proposed: [zuul/zuul] 858250: web: Put status icon into one label https://review.opendev.org/c/zuul/zuul/+/858250 | 04:14 | |
| -@gerrit:opendev.org- Ian Wienand proposed: [zuul/zuul] 858250: web: Put status icon into one label https://review.opendev.org/c/zuul/zuul/+/858250 | 04:15 | |
| -@gerrit:opendev.org- Ian Wienand proposed: [zuul/zuul] 858250: web: Put status icon into one label https://review.opendev.org/c/zuul/zuul/+/858250 | 04:24 | |
| -@gerrit:opendev.org- Ian Wienand proposed: [zuul/zuul-jobs] 858256: configure-mirrors: fix typo in 9-stream enablement list https://review.opendev.org/c/zuul/zuul-jobs/+/858256 | 06:17 | |
| -@gerrit:opendev.org- Simon Westphahl proposed: | 06:40 | |
| - [zuul/zuul] 856523: Add span for builds and propagate via request https://review.opendev.org/c/zuul/zuul/+/856523 | ||
| - [zuul/zuul] 857421: Trace merge requests and merger operations https://review.opendev.org/c/zuul/zuul/+/857421 | ||
| -@gerrit:opendev.org- Simon Westphahl proposed on behalf of James E. Blair https://matrix.to/#/@jim:acmegating.com: | 06:40 | |
| - [zuul/zuul] 854458: Add support for configuring and testing tracing https://review.opendev.org/c/zuul/zuul/+/854458 | ||
| - [zuul/zuul] 855096: Tracing: implement span save/restore https://review.opendev.org/c/zuul/zuul/+/855096 | ||
| - [zuul/zuul] 855293: Add tracing tutorial https://review.opendev.org/c/zuul/zuul/+/855293 | ||
| -@gerrit:opendev.org- Simon Westphahl proposed: | 06:44 | |
| - [zuul/zuul] 856523: Add span for builds and propagate via request https://review.opendev.org/c/zuul/zuul/+/856523 | ||
| - [zuul/zuul] 857421: Trace merge requests and merger operations https://review.opendev.org/c/zuul/zuul/+/857421 | ||
| - [zuul/zuul] 858096: Trace node request phase https://review.opendev.org/c/zuul/zuul/+/858096 | ||
| -@gerrit:opendev.org- Simon Westphahl proposed on behalf of James E. Blair https://matrix.to/#/@jim:acmegating.com: | 06:44 | |
| - [zuul/zuul] 854458: Add support for configuring and testing tracing https://review.opendev.org/c/zuul/zuul/+/854458 | ||
| - [zuul/zuul] 855096: Tracing: implement span save/restore https://review.opendev.org/c/zuul/zuul/+/855096 | ||
| - [zuul/zuul] 855293: Add tracing tutorial https://review.opendev.org/c/zuul/zuul/+/855293 | ||
| -@gerrit:opendev.org- Simon Westphahl proposed: | 09:20 | |
| - [zuul/zuul] 857421: Trace merge requests and merger operations https://review.opendev.org/c/zuul/zuul/+/857421 | ||
| - [zuul/zuul] 858096: Trace node request phase https://review.opendev.org/c/zuul/zuul/+/858096 | ||
| -@gerrit:opendev.org- Artem Goncharov proposed: [zuul/zuul] 849033: Initial implementation of the gitea driver https://review.opendev.org/c/zuul/zuul/+/849033 | 09:22 | |
| -@gerrit:opendev.org- Artem Goncharov proposed: [zuul/zuul] 849670: Improve gitea trigger testing https://review.opendev.org/c/zuul/zuul/+/849670 | 09:23 | |
| -@gerrit:opendev.org- Artem Goncharov proposed: | 09:23 | |
| - [zuul/zuul] 849680: Implement gitea reporter interface https://review.opendev.org/c/zuul/zuul/+/849680 | ||
| - [zuul/zuul] 849719: Implement gitea commit status reporter https://review.opendev.org/c/zuul/zuul/+/849719 | ||
| -@gerrit:opendev.org- Artem Goncharov proposed: [zuul/zuul] 849720: Implement gitea comment trigger https://review.opendev.org/c/zuul/zuul/+/849720 | 09:23 | |
| -@gerrit:opendev.org- Artem Goncharov proposed: | 09:23 | |
| - [zuul/zuul] 849727: Add gitea pr dyn_reconf test https://review.opendev.org/c/zuul/zuul/+/849727 | ||
| - [zuul/zuul] 849728: Implement gitea refs https://review.opendev.org/c/zuul/zuul/+/849728 | ||
| -@gerrit:opendev.org- Artem Goncharov proposed: | 09:23 | |
| - [zuul/zuul] 850008: Implement gitea merge reporter https://review.opendev.org/c/zuul/zuul/+/850008 | ||
| - [zuul/zuul] 850413: Implement gitea requirement https://review.opendev.org/c/zuul/zuul/+/850413 | ||
| -@gerrit:opendev.org- Artem Goncharov proposed: [zuul/zuul] 850883: Implement gitea review trigger https://review.opendev.org/c/zuul/zuul/+/850883 | 09:24 | |
| -@gerrit:opendev.org- Artem Goncharov proposed: | 09:24 | |
| - [zuul/zuul] 850898: Implement gitea label_updated event trigger https://review.opendev.org/c/zuul/zuul/+/850898 | ||
| - [zuul/zuul] 850941: Tune gitea trigger events https://review.opendev.org/c/zuul/zuul/+/850941 | ||
| -@gerrit:opendev.org- Simon Westphahl proposed: | 09:25 | |
| - [zuul/zuul] 857421: Trace merge requests and merger operations https://review.opendev.org/c/zuul/zuul/+/857421 | ||
| - [zuul/zuul] 858096: Trace node request phase https://review.opendev.org/c/zuul/zuul/+/858096 | ||
| @ekapoun1:matrix.org | Hello, does [job.required-projects.override-checkout](https://zuul-ci.org/docs/zuul/latest/config/job.html#attr-job.required-projects.override-checkout) support a git hash as input? Or just a branch name or tag? The docs say: "This attribute is used to override that behavior and indicate that this job should, regardless of the branch for the queue item, use the indicated ref (i.e., branch or tag) instead, for only this project." I can't seem to get it to work though, but my setup may be a bit awkward as well. | 11:19 |
|---|---|---|
| -@gerrit:opendev.org- Simon Westphahl proposed: [zuul/zuul] 858372: Create link to previous buildset span https://review.opendev.org/c/zuul/zuul/+/858372 | 12:56 | |
| @mbecker12:matrix.org | > corvus: ^ I reworked the tests a bit and I stumbled across the 'blocking' argument in the zk.lockNode function. Is there a reason why it has to be blocking=True in the delete command? Is it okay if it's not blocking for the hold command? What's the underlying reasoning here? I also left some comments in the patch again if you prefer the discussion to be held there :) | 13:34 |
| Hi, I would like to get some more input on my patch if you have time https://review.opendev.org/c/zuul/nodepool/+/853993 | ||
| -@gerrit:opendev.org- Per Wiklund proposed: [zuul/zuul] 858382: Expose metastatic slot information in hostvars https://review.opendev.org/c/zuul/zuul/+/858382 | 13:36 | |
| -@gerrit:opendev.org- Per Wiklund proposed: [zuul/zuul] 858382: Expose metastatic slot information in hostvars https://review.opendev.org/c/zuul/zuul/+/858382 | 13:50 | |
| @clarkb:matrix.org | > <@ekapoun1:matrix.org> Hello, does [job.required-projects.override-checkout](https://zuul-ci.org/docs/zuul/latest/config/job.html#attr-job.required-projects.override-checkout) support a git hash as input? Or just a branch name or tag? The docs say: "This attribute is used to override that behavior and indicate that this job should, regardless of the branch for the queue item, use the indicated ref (i.e., branch or tag) instead, for only this project." I can't seem to get it to work though, but my setup may be a bit awkward as well. | 13:56 |
| I think it needs to be a named ref. Not a revision | ||
| @ekapoun1:matrix.org | > <@clarkb:matrix.org> I think it needs to be a named ref. Not a revision | 14:12 |
| Interesting. I'm scouring some other repos in my org. and noticed someone using a git hash as input to the attribute, but on the job definition level. I've been trying to define the attribute on a job from a project level, but it seems Zuul doesn't respect the attribute (but also doesn't fail). | ||
| @ekapoun1:matrix.org | > <@clarkb:matrix.org> I think it needs to be a named ref. Not a revision | 14:12 |
| * Interesting. I'm scouring some other repos in my org. and noticed someone using a git hash as input to the attribute, but on the job definition level. I've been trying to define the attribute on a job from a project level, but it seems Zuul doesn't respect the attribute in this way (but also doesn't fail). | ||
| @ekapoun1:matrix.org | Also, is it possible to use the value from a job1.provides attribute as input to an job2.override-checkout using job2.requires? | 14:41 |
| @jim:acmegating.com | ekapoun1: no, but you can always update the checkout in the job. the main difference is that zuul won't use that to decide what to checkout for roles and playbooks. | 14:43 |
| @ekapoun1:matrix.org | > <@jim:acmegating.com> ekapoun1: no, but you can always update the checkout in the job. the main difference is that zuul won't use that to decide what to checkout for roles and playbooks. | 14:45 |
| Nice, so if I'm understanding you correctly, there is no "risk" in there being a mismatch in job definitions if you were to check out an older git hash of a repo which happens to either not have the job in question either defined, or defined in another way? The jobs are set and frozen, and any subsequent checkout of another git hash within the job does not have an effect? | ||
| @jim:acmegating.com | ekapoun1: there's a lot to unpack there, and i'm not going to say "no risk" in an informal chat. but in general, it is true that the job definition is decided and frozen before the job starts. i'd have to do a more thorough analysis to say whether there are any conditions under which updating a checkout within a job could alter a playbook or role used by the job. but if no playbooks or roles are indicated, then zuul shouldn't care. | 14:52 |
| @ekapoun1:matrix.org | > <@jim:acmegating.com> ekapoun1: there's a lot to unpack there, and i'm not going to say "no risk" in an informal chat. but in general, it is true that the job definition is decided and frozen before the job starts. i'd have to do a more thorough analysis to say whether there are any conditions under which updating a checkout within a job could alter a playbook or role used by the job. but if no playbooks or roles are indicated, then zuul shouldn't care. | 14:55 |
| I understand, no worries. If we are to assume that the job definitions are frozen before the jobs start, the only risk is if the job that has been frozen is, through a playbook or role, referencing files present in a newer git hash of a branch which don't exist in the older checked out git hash of that branch. That is logical though. | ||
| @ekapoun1:matrix.org | > <@jim:acmegating.com> ekapoun1: there's a lot to unpack there, and i'm not going to say "no risk" in an informal chat. but in general, it is true that the job definition is decided and frozen before the job starts. i'd have to do a more thorough analysis to say whether there are any conditions under which updating a checkout within a job could alter a playbook or role used by the job. but if no playbooks or roles are indicated, then zuul shouldn't care. | 15:02 |
| * I understand, no worries. If we are to assume that the job definitions are frozen before the jobs start, the largest risk I guess is if the job that has been frozen is, through a playbook or role, referencing files present in a newer git hash of a branch which don't exist in the older checked out git hash of that branch. That is logical though. | ||
| @clarkb:matrix.org | I had to do a hard refresh to see it but the new task descriptions on the deep linked cards in the console viewer are great | 16:49 |
| @clarkb:matrix.org | ianw: I really like that change | 16:49 |
| @clarkb:matrix.org | corvus: did you see https://etherpad.opendev.org/p/140NVVGa7i530H0STCmw ? Wondering if you think we should file something like that against Ansible | 17:18 |
| @jim:acmegating.com | Clark: that's awesome, sorry i missed that when you posted it. yes i think that would be really helpful. | 17:20 |
| @fungicide:matrix.org | Clark: i marked out part of a word which i think was a typo in the last paragraph | 17:21 |
| @fungicide:matrix.org | otherwise, i think that sums the situation up quite well | 17:22 |
| @clarkb:matrix.org | Yup that was a typo. Thanks | 17:22 |
| @clarkb:matrix.org | I'll put that into a github issue against ansible unless there is a better location for it | 17:22 |
| @clarkb:matrix.org | Also just pushed https://review.opendev.org/c/openstack/devstack/+/858436 to test devstack jobs with ansible 6 | 17:22 |
| @clarkb:matrix.org | those jobs tend to have really good coverage of things that might be unhappy with new ansible | 17:23 |
| @fungicide:matrix.org | in other words, openstack is really good at breaking things you would never think of breaking | 17:24 |
| @clarkb:matrix.org | I appreciate that communities struggle with getting poor bug reports, but it is frustrating when there isn't any leeway in a the bug report template to submit a report that deviates | 17:55 |
| @clarkb:matrix.org | https://github.com/ansible/ansible/issues/78809 | 18:05 |
| @clarkb:matrix.org | Ansible 6 against that devstack change looks good. One job did fail but it seems to be for a reason unrelated to ansible. I've rechecked to be sure | 19:51 |
| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: [zuul/nodepool] 858447: Aws: add support for volume iops and throughput https://review.opendev.org/c/zuul/nodepool/+/858447 | 20:19 | |
| @jim:acmegating.com | if the ansible 6 stuff is looking good, then i think https://review.opendev.org/857796 to remove ansible 2 is the next thing needed for the 7.0 release. at this point, i think the dates in https://etherpad.opendev.org/p/qF7VE9HzqPVzsCyZLWxb now need to be pushed back 1 week (i'll update that now) | 20:39 |
| @clarkb:matrix.org | corvus: apparently the issue was we used and invalid shebang | 20:47 |
| @clarkb:matrix.org | I'm still not sure I quite understand what ansibel is attempted to do there. I guess determine if python2 vs python3 should be used? | 20:47 |
| @clarkb:matrix.org | But our change is apparently a correct enough one | 20:48 |
| -@gerrit:opendev.org- Zuul merged on behalf of James E. Blair https://matrix.to/#/@jim:acmegating.com: [zuul/zuul] 855966: Use json view for complex artifact metadata https://review.opendev.org/c/zuul/zuul/+/855966 | 21:40 | |
| @jim:acmegating.com | Clark: so ansible reads "/usr/bin/python" as "the python executable ansible thinks is appropriate based on whether it's localhost (in which case it's the ansible controller's python) or not (in which case it's ansible_python_path). and that python might be python3. and presumably reads "/usr/bin/python3" as the same but for python3 even if running under python2 (?? i dunno ??) | 21:45 |
| @clarkb:matrix.org | ya I think that further clarification could be helpful there but something along those lines appears to be what is happening | 21:45 |
| @jim:acmegating.com | Clark: i feel like that's fine if they're basically asserting that these aren't actual python scripts, and therefore the shebang doesn't mean what it normally means, but instead, in the "ansible python file language" it means this other thing. that's cool and entirely their perogative. but while that makes the suggestion a "correct" suggestion for ansible, those shebangs are definitely not correct for python scripts. | 21:47 |
| @clarkb:matrix.org | Agreed | 21:47 |
| @clarkb:matrix.org | They are overloading the purpose of the shebang | 21:47 |
| @jim:acmegating.com | i think a good clarification would be to say something to that effect in the module docs (basically: these are some magic works that mean special things to ansible -- say "#!/usr/bin/python" to make it do the right thing) | 21:47 |
| @clarkb:matrix.org | In the dev guide where it already suggests having a shebang maybe? | 21:48 |
| @clarkb:matrix.org | do you want to repsond to the bug with that suggestion or should I? | 21:48 |
| @jim:acmegating.com | yeah, like i didn't get the particular magic they describe from the dev guide. lemme re-read that with the new understanding real quick | 21:48 |
| @iwienand:matrix.org | > <@clarkb:matrix.org> I had to do a hard refresh to see it but the new task descriptions on the deep linked cards in the console viewer are great | 21:52 |
| yeah, makes the details a bit more obvious. https://review.opendev.org/c/zuul/zuul/+/858243/ is a fix -- I realised we don't *have* to use React components and that should really fix the very narrow view. I should have done that all along, but my intuition with writing React is ... developing :) On top of that are some more subjective changes that have been percolating as i worked on the other bits | ||
| @jim:acmegating.com | Clark: it's not called out in https://docs.ansible.com/ansible/latest/dev_guide/developing_modules_general.html but https://docs.ansible.com/ansible/latest/dev_guide/developing_modules_documenting.html#python-shebang-utf-8-coding does say that. it's not quite as "no really you should say /usr/bin/python even if you expect to use a different interpreter" as i'd like, but technically it does say what the bug report says...) | 21:53 |
| @clarkb:matrix.org | corvus: even there it just says "this allows ansible_python_interpreter" to work | 21:53 |
| @clarkb:matrix.org | which doesn't really convey what is happening here to me | 21:53 |
| -@gerrit:opendev.org- Zuul merged on behalf of James E. Blair https://matrix.to/#/@jim:acmegating.com: [zuul/zuul] 856210: Log more info on gerrit 403 errors https://review.opendev.org/c/zuul/zuul/+/856210 | 21:53 | |
| @jim:acmegating.com | Clark: i agree | 21:55 |
| @jim:acmegating.com | (in fact, we *don't* want ansible_python_interpreter to "work" on localhost) | 21:55 |
| @clarkb:matrix.org | Maybe a suggestion that they update that section to indicate using #!/usr/bin/python in the shebang to know running under ansible_python_interpreter is correct would be good. I think where I trip up here is the shebang is literally saying to use something else so why would that mean use what ansible has detected | 21:55 |
| @jim:acmegating.com | (so we might have thought that we should not use the shebang after reading that) | 21:55 |
| @clarkb:matrix.org | Describing the mechanism basically rather than "do this so X works" would be helpful | 21:57 |
| @clarkb:matrix.org | I went ahead and followed up with why I find this confusing and how I think updating the documentation will help | 22:37 |
| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: [zuul/nodepool] 858447: Aws: add support for volume iops and throughput https://review.opendev.org/c/zuul/nodepool/+/858447 | 23:17 | |
| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: [zuul/nodepool] 807806: Add "slots" to static node driver https://review.opendev.org/c/zuul/nodepool/+/807806 | 23:40 | |
| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: | 23:56 | |
| - [zuul/nodepool] 807806: Add "slots" to static node driver https://review.opendev.org/c/zuul/nodepool/+/807806 | ||
| - [zuul/nodepool] 811016: Expose slot number from metastatic driver https://review.opendev.org/c/zuul/nodepool/+/811016 | ||
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!