| @pernordeman:matrix.org | Hi, Is is possible to set the value of **override-checkout** using the **zuul_return** module? | 10:29 |
|---|---|---|
| @pernordeman:matrix.org | I want to which the context/branch of which a set of child_jobs are running based on a playbook runned by the parent job, e.g the child_jobs should thereby inherit the **override-checkout** value | 10:33 |
| @sylvass:albinvass.se | No, is it just the repo state on the machine you need to manage or are you also trying to configure which job variants to run? | 10:41 |
| If its just the repo state you can pass variables with `zuul_return` to a dependent job and run `git checkout <branch>` before running any tests | ||
| @pernordeman:matrix.org | I want to in some cases avoid the auto-rebasing that zuul does, so its in the majority only repo state that is switched (since job variants are slow moving). | 11:02 |
| Each job run on its own machine, so the checkout need to be done for each. | ||
| are parent pre-tasks inherited for each child-jobs? e.g this pre-task would then do """git checkout <branch> """ | ||
| @pernordeman:matrix.org | * I want to in some cases avoid the auto-rebasing that zuul does, so its in the majority only repo state that is switched (since job variants are slow moving). | 11:03 |
| Each job run on its own machine, so the checkout need to be done for each. | ||
| are parent pre-tasks inherited for each child-jobs? e.g this pre-task would then do `git checkout \<branch>` | ||
| @sylvass:albinvass.se | > I want to in some cases avoid the auto-rebasing that zuul does, so its in the majority only repo state that is switched (since job variants are slow moving). | 11:10 |
| Do you want to run a gate queue without a speculative repo state? | ||
| @sylvass:albinvass.se | if so, then you could just use a regular check pipeline and let user manually merge their changes once checks have passed to then rely on regular regression testing in a post-merge pipeline | 11:12 |
| @sylvass:albinvass.se | ^ you would still test branch + change in check but it wouldn't share a queue with other changes | 11:13 |
| @sylvass:albinvass.se | or is it that you only want to test in a speculative gate queue for some jobs? Then I'd just remove those jobs from gate and only run them in check/post :) | 11:16 |
| @pernordeman:matrix.org | hmm, not quite sure i follow and sorry if im unclear. | 11:52 |
| I have no intention(currently atleast) of merging the commits being tested but rather testing them based on a previous repo state/version. | ||
| -@gerrit:opendev.org- Felix Edel proposed: | 12:29 | |
| - [zuul/zuul] 916284: Implement new status page https://review.opendev.org/c/zuul/zuul/+/916284 | ||
| - [zuul/zuul] 916285: Make helper functions available to other components https://review.opendev.org/c/zuul/zuul/+/916285 | ||
| - [zuul/zuul] 916286: Implement QueueItemPopover https://review.opendev.org/c/zuul/zuul/+/916286 | ||
| - [zuul/zuul] 916287: Implement PipelineDetails view https://review.opendev.org/c/zuul/zuul/+/916287 | ||
| - [zuul/zuul] 916288: Sort pipelines on status page by number of queue items https://review.opendev.org/c/zuul/zuul/+/916288 | ||
| - [zuul/zuul] 916289: Align QueueItem and QueueItemPopover https://review.opendev.org/c/zuul/zuul/+/916289 | ||
| - [zuul/zuul] 916290: Align job progress bars and job result labels https://review.opendev.org/c/zuul/zuul/+/916290 | ||
| - [zuul/zuul] 916744: Visualize branches in ChangeQueues https://review.opendev.org/c/zuul/zuul/+/916744 | ||
| - [zuul/zuul] 916867: Implement admin actions (promote, dequeue) in new QueueItem component https://review.opendev.org/c/zuul/zuul/+/916867 | ||
| - [zuul/zuul] 916973: Show queue lengths and fetching state on status page https://review.opendev.org/c/zuul/zuul/+/916973 | ||
| - [zuul/zuul] 916974: Add switch to show/hide empty pipelines and queues https://review.opendev.org/c/zuul/zuul/+/916974 | ||
| - [zuul/zuul] 917039: Add support for dark mode to new status view components https://review.opendev.org/c/zuul/zuul/+/917039 | ||
| - [zuul/zuul] 917952: Show last reconfiguration time on status page https://review.opendev.org/c/zuul/zuul/+/917952 | ||
| @bridgefan:matrix.org | I'm just jumping in and haven't seen the full conversation but... snaz, I think the best way you can test commits without auto-rebasing is to put them on check pipeline like Albin Vass said | 13:41 |
| @bridgefan:matrix.org | In my experience post submission (gate/submit) jobs auto-rebase, but pre-submission (check) don't | 13:42 |
| @bridgefan:matrix.org | This is assuming that you are committing to an untrusted-project (which allows pre-submission testing). | 13:42 |
| @sylvass:albinvass.se | So you're trying to push change A to master (or create a PR to master) but want to test master@<rev> ? | 13:44 |
| @bridgefan:matrix.org | Also, pre-run and post-run tasks are inherited from parents. I think anything in parent jobs that child doesn't override will stay | 13:44 |
| @bridgefan:matrix.org | If a particular base commit is needed (and not just the commit at time of push) you could create a branch for each base rev and have the jobs run on check pipeline for those | 13:46 |
| @pernordeman:matrix.org | Yepp. | 13:57 |
| @pernordeman:matrix.org | * Yepp. | 13:57 |
| @sylvass:albinvass.se | snaz: depending on what you're trying to achieve, this may be a good idea ^ | 13:57 |
| @pernordeman:matrix.org | Yepp that is a alternative that we explore, but it does not scale that nice( if i interpret it correctly) and would change our wow a bit. | 14:07 |
| @bridgefan:matrix.org | If I may ask, why do you want to test changes against a specific rev but not merge them? | 14:08 |
| @bridgefan:matrix.org | You are right, that if you have to do this at scale, it would be tricky. | 14:09 |
| @bridgefan:matrix.org | One thing I've seen done is to make a zuul job that uses a gerrit REST api to create a new commit. The idea is that you can automate the creation of commitsthen have check pipelines on these | 14:11 |
| @clarkb:matrix.org | zuul prepares the upstream state as well as the speculative state. You can also run jobs periodically against an upstream state. Or run jobs when branches update | 14:57 |
| -@gerrit:opendev.org- Simon Westphahl proposed: | 15:57 | |
| - [zuul/zuul] 914184: Vendor persistent recursive watch Kazoo support https://review.opendev.org/c/zuul/zuul/+/914184 | ||
| - [zuul/zuul] 917987: wip: Prototype cooperative zuul-launcher https://review.opendev.org/c/zuul/zuul/+/917987 | ||
| @tristanc_:matrix.org | felixedel: the new status page looks great, thanks! My only concern is that it is fully functional only at the end of the stack. Would it be possible to add the new component to a new route path so that we can do the switch once everything is merged? Perhaps we could even keep the old component for a while in case someone prefer the old view. | 19:25 |
| @jim:acmegating.com | tristanC: i think we can view that stack as all-or-nothing; we'll merge them all at once. | 19:30 |
| @jim:acmegating.com | tristanC: thanks for the reviews; i've also asked felix to make a short design document to make sure we're covering all the new and existing use cases and not regressing | 19:39 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!