| @plscosta:matrix.org | yes you are correct... i will just leave the scenario here: | 00:00 |
|---|---|---|
| - pipeline 1 (runs a couple of jobs and has 3 possible outputs) | ||
| 1a) it fails and gives a -1 (this means that there is something wrong with the change and needs fixing) | ||
| 1b) everything is ok but change is complex and needs human review (just gives a +1) | ||
| 1c) everything is ok and it is a simple change (gives a +1 and comments the change "change ok to +2") | ||
| - pipeline 2 should run after the first one is finished and validate 1c) outcome of the first pipeline | ||
| I could use 1c) to trigger the second pipeline, but at this point the pipeline has not finished yet and does not run because the +1 was not yet given... | ||
| This was what i had in mind: | ||
| - pipeline: | ||
| name: some-name | ||
| description: > | ||
| this will do review | ||
| require: | ||
| gerrit: | ||
| open: True | ||
| current-patchset: True | ||
| approval: | ||
| - Verified: 1 | ||
| - event: comment-added | ||
| comment: some-comment | ||
| If i could have the "event - comment" in the requirement section would be great... but has Fungi explained it guerrit change does not have the full comment history scrapped, so this won't work... | ||
| Thanks for any help/input. | ||
| @fungicide:matrix.org | also possible i'm still not understanding. when 1c vote is left by the first pipeline, how can it not have finished yet? a pipeline only reports a result once all of its jobs in the buildset have completed | 00:03 |
| @fungicide:matrix.org | unless you're using something other than the pipeline to do the voting for 1c (like a gerrit account accessed by one of the jobs run in that pipeline) | 00:03 |
| @fungicide:matrix.org | and if that's what's going on, you've basically created an ad hoc additional pipeline within the job that's applying the tc vote, so that would make more sense as a separate actual pipeline in that case voting in a different label | 00:05 |
| @fungicide:matrix.org | * and if that's what's going on, you've basically created an ad hoc additional pipeline within the job that's applying the 1c vote, so that would make more sense as a separate actual pipeline in that case voting in a different label | 00:06 |
| @plscosta:matrix.org | Hello fungi | 08:19 |
| so pipeline 1 runs these jobs: | ||
| JP1) job1 (does some checks, can be successful or fail) | ||
| JP2) job2 (does some checks and if ok writes a comment in gerrit) | ||
| JP3) job3 (does some checks, can be successful or fail)) | ||
| JPN) jobn (other jobs doing other checks, can be successful or fail) | ||
| When the pipeline ends with success you get a +1 in the change... and possibly also a comment posted by JP2). | ||
| I need to validate in pipeline2 that comment posted by JP2) is in the change, and the trigger wont work in this case because the comment posted by JP2) gets posted as soon as the job finishes and the pipeline is still running the rest of the jobs...so the change does not have the +1 at this time and won't run... | ||
| What I am think is the possibility of changing JP2) so that it can run in pipeline 2 and validate from there (with success/failure) hopefully this will be doable... | ||
| @plscosta:matrix.org | * Hello fungi | 08:20 |
| so pipeline 1 runs these jobs: | ||
| JP1) job1 (does some checks, can be successful or fail) | ||
| JP2) job2 (does some checks and if ok writes a comment in gerrit) | ||
| JP3) job3 (does some checks, can be successful or fail)) | ||
| JPN) jobn (other jobs doing other checks, can be successful or fail) | ||
| When the pipeline ends with success you get a +1 in the change... and possibly also a comment posted by JP2). | ||
| I need to validate in pipeline2 that comment posted by JP2) is in the change, and the trigger wont work in this case because the comment posted by JP2) gets posted as soon as the job finishes and the pipeline is still running the rest of the jobs...so the change does not have the +1 at this time and won't run... | ||
| What I am think is the possibility of changing JP2) so that it can run in pipeline 2 and validate from there (with success/failure) hopefully this will be doable... | ||
| -@gerrit:opendev.org- Simon Westphahl proposed: | 10:17 | |
| - [zuul/nodepool] 885958: Initialize retries attribute in SM launcher early https://review.opendev.org/c/zuul/nodepool/+/885958 | ||
| - [zuul/nodepool] 885959: Log and re-raise cache startup errors https://review.opendev.org/c/zuul/nodepool/+/885959 | ||
| - [zuul/nodepool] 885960: Copy cached objects in tree cache before iterating https://review.opendev.org/c/zuul/nodepool/+/885960 | ||
| @jim:acmegating.com | plscosta: instead of having the job use the gerrit api to post the comment in jp2, you could have zuul do it with zuul_return as a warning or a file comment: | 14:34 |
| * https://acmegating.com/docs/zuul/latest/job-content.html#leaving-warnings | ||
| * https://acmegating.com/docs/zuul/latest/job-content.html#leaving-file-comments | ||
| -@gerrit:opendev.org- Zuul merged on behalf of Alfredo Moralejo: [zuul/zuul-jobs] 883790: Use release CentOS SIGS repo to install openvswitch in C9S https://review.opendev.org/c/zuul/zuul-jobs/+/883790 | 14:44 | |
| @fungicide:matrix.org | though i still don't think the existence nor absence of that comment can be used post facto as one of the requirements for enqueuing in a subsequent pipeline like the presence or absence of a vote in a specific label can | 14:46 |
| @fungicide:matrix.org | which sounded like part of the design criteria | 14:46 |
| @jim:acmegating.com | yes; though it may be able to be used as part of a trigger comment match (i was responding only to the most recent message which described that as a problem( | 14:48 |
| @jim:acmegating.com | * yes; though it may be able to be used as part of a trigger comment match (i was responding only to the most recent message which described that as a problem) | 14:48 |
| @jim:acmegating.com | but generally, yeah, if you're trying to indicate and match on something stateful, then, well, that's what review labels are for :) | 14:49 |
| @fungicide:matrix.org | yes, agreed. as long as the comment is added after all other criteria are met it would work. i guess if they're all in one buildset then that would be the case? are zuul-return comments only added when the buildset reports or as soon as the job specifying them completes? | 14:50 |
| @jim:acmegating.com | buildset reports | 14:51 |
| @fungicide:matrix.org | yeah, then it seems like that could be a solution for the problem. make the enqueuing criteria for the subsequent pipeline be a comment-added trigger matching the comment pattern and requiring the +1 vote from the buildset report | 14:53 |
| @jim:acmegating.com | fragile but technically workable | 14:53 |
| @plscosta:matrix.org | Hello there, | 14:56 |
| This does actually sound like it could work.. what criteria would make the job write the warning? | ||
| @plscosta:matrix.org | if the jobs succeeds it writes the warning? and if it fails it does not? | 14:56 |
| @jim:acmegating.com | you just add a zuul_return task; it will write it in all cases then (success or failure) | 14:56 |
| @plscosta:matrix.org | hum... maybe missing something... but if the job fails wont it trigger the pipeline anyway? | 14:57 |
| @jim:acmegating.com | just be aware that triggering on non-repeatable ephemeral events can be tricky; make sure you have another way of triggering. | 14:58 |
| @jim:acmegating.com | plscosta: then wrap the zuul_return in a conditional that only does it if the job isn't failing | 14:58 |
| @plscosta:matrix.org | ok i will give that a go | 14:59 |
| @plscosta:matrix.org | thanks | 14:59 |
| @jim:acmegating.com | good luck :) | 14:59 |
| @plscosta:matrix.org | Luck favors the prepared :D | 15:00 |
| @fungicide:matrix.org | you can also make the existence of a verified +1 be a requirement for that comment-added trigger if you're worried about it trying to enqueue on that comment when the vote from the buildset was -1 | 15:15 |
| @fungicide:matrix.org | also you probably want to limit the trigger to comments from the account used by your zuul, so that a normal user couldn't trigger it by leaving the same comment | 15:20 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!