| @smashedpotato:matrix.org | Hi. An absolute beginner question: I'd like to cut corners and have Zuul proceed from the check phase of a pipeline directly to the gating phase without the necessity of manual code review + upvote in between. Is there a way to achieve this? This because I'm currently working alone and have a huge pile of repos to combine. Gerrit may come into play later if I get more people to help me. | 12:58 |
|---|---|---|
| @smashedpotato:matrix.org | * Hi. An absolute beginner question: I'd like to cut corners and have Zuul proceed from the check phase of a pipeline directly to the gating phase without the necessity of manual code review + upvote in between. Is there a way to achieve this? This because I'm currently working alone and have a huge pile of repos to combine. Gerrit code reviews may come into play later if I get more people to help me. | 14:02 |
| @fungicide:matrix.org | smashedpotato: basically you want all proposed changes to merge if they pass testing? you could probably even get rid of the check pipeline entirely in that configuration, since it exists to provide information to reviewers so they can decide whether or not to approve something | 14:08 |
| @smashedpotato:matrix.org | Yes, merge if they pass testing. | 14:08 |
| @fungicide:matrix.org | the main place i'd caution you is if you add any sensitive data like credentials to a repository, someone proposing a change could alter the configuration to expose that data | 14:09 |
| @fungicide:matrix.org | so you'll probably still want a manual review step for your base/config repo(s) before gating | 14:09 |
| @fungicide:matrix.org | oh, or are you saying you also don't want to have to hook zuul up to a code review system at all? that might get harder, i don't think zuul has the capability currently to push commits with the git source driver | 14:11 |
| @smashedpotato:matrix.org | Good point. Ideally, all passwords, credentials etc in the repos are for building, testing and integration only, so I don't see it as a big risk or problem. The production version would have its own ones outside versioning. | 14:11 |
| @fungicide:matrix.org | but also without a code review system, i'm not sure where people would propose their changes | 14:11 |
| @fungicide:matrix.org | i'm pretty sure you could achieve the automated propose->test->merge workflow you're asking for, but you'd still need a code review system (gerrit, gitlab, github, pagure...) for people to propose their changes into and for zuul to instruct that the change should merge | 14:13 |
| @smashedpotato:matrix.org | Yes, a code review system is redundant now that I'm alone but once there are more people, a review system is needed. A "review" for me now would be simply a decision that "now I have new code that could do" and then Zuul would build and test everything. | 14:14 |
| @fungicide:matrix.org | i'd start out by taking the trigger configuration from an example check pipeline and the outcomes from a gate pipeline and combining them into a custom pipeline. the tricky part will be making sure that all the merge requirements are satisfied up front (i.e. by configuring gerrit not to require a code review or approval for the affected projects) | 14:16 |
| @fungicide:matrix.org | others in here may have additional suggestions though (or be aware of reasons this won't actually work the way i expect) | 14:18 |
| @smashedpotato:matrix.org | Thanks for your suggestions. | 14:19 |
| @mhuin:matrix.org | What code review system are you using? since you want to implement immediate gating, there still needs to be a gate to speak of, ie a code review system | 14:31 |
| @smashedpotato:matrix.org | I use no review system at the moment, since there's is no need for it being a lone developer (for the time being). | 14:33 |
| @smashedpotato:matrix.org | So the whole issue for me as I can see it is, can I start off with Zuul without a code review system and then later incorporate one when needed? | 14:35 |
| @fungicide:matrix.org | smashedpotato: i can't think of any way to do that. to rephrase what i said earlier, where would you "propose" the changes you want zuul to test? right now zuul knows how to listen to events from a variety of code review systems to find out when changes have been proposed so it can start testing them | 14:43 |
| @mhuin:matrix.org | you can, there's a git driver, but there won't be any trigger that corresponds to a gating event | 14:43 |
| @fungicide:matrix.org | well, also as i mentioned before, i don't think the git source driver has the ability to push anything into a repository once gating completes | 14:43 |
| @fungicide:matrix.org | it's basically read-only | 14:44 |
| @clarkb:matrix.org | One way to think about it is that Zuul is a type of code reviewer | 14:44 |
| @smashedpotato:matrix.org | Hmmm ... sorry, being unfamiliar with Zuul I may have some trouble formulating myself in proper terms. A "proposal" in my case could be committinq a suitably named git branch, where the name of the branch matches some predefined regexp. This would then ideally be enough to trigger a Zuul build and test. | 14:46 |
| @fungicide:matrix.org | having only one git branch for proposed changes would limit zuul to only being able to test one change at a time. zuul is designed for accurate scalable parallel testing | 14:47 |
| @fungicide:matrix.org | anyway, i think you can accomplish the automation you want, but would need a code review system. the workflow would basically be 1. propose change to the code review system, 2. zuul sees the change you proposed and starts to run tests, 3. if tests succeed zuul tells the code review system to merge the change to the intended branch | 14:48 |
| @smashedpotato:matrix.org | I know it may be overkill in the beginning but there's a number of git repos out of which the different sw components would be built. Having more committers later, the setting changes. | 14:50 |
| @weebull:matrix.org | > <@smashedpotato:matrix.org> I know it may be overkill in the beginning but there's a number of git repos out of which the different sw components would be built. Having more committers later, the setting changes. | 16:30 |
| Do you have a place you push your branches to? A GitHub/gitlab/something else? If so, it would be a case of pushing the branch, creating a pull request to let Zuul know it should test that branch, and everything can go as you want. Zuul is your reviewer and it will put information in the PR if (for example) it fails. | ||
| @weebull:matrix.org | If it passes, it merges and closes the PR. You can come back to any open PRs in the future. | 16:31 |
| @jim:acmegating.com | smashedpotato: the single-user workflow with gerrit is good. you can set it up so you just `git push origin HEAD:refs/for/master` (or `git review`) and if it passes tests it will auto-merge, and if it doesn't, you have a nice listing of "open" changes that show you what you need to address. the zuul quickstart tutorial will set up a gerrit; you can use that as a basis. you can just run the gerrit server where ever you are running zuul. for a single user, it's lightweight (single process, no extra dependencies). | 16:50 |
| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: [zuul/zuul] 903911: Produce consistent merge commit shas https://review.opendev.org/c/zuul/zuul/+/903911 | 17:26 | |
| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: [zuul/zuul] 904024: DNM: prng test https://review.opendev.org/c/zuul/zuul/+/904024 | 17:45 | |
| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: [zuul/zuul] 904028: Remove file matcher special case for empty file list https://review.opendev.org/c/zuul/zuul/+/904028 | 18:50 | |
| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: [zuul/zuul] 904030: Fix multi-scheduler timer unit test https://review.opendev.org/c/zuul/zuul/+/904030 | 18:58 | |
| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: | 19:05 | |
| - [zuul/zuul] 904030: Fix multi-scheduler timer unit test https://review.opendev.org/c/zuul/zuul/+/904030 | ||
| - [zuul/zuul] 903911: Produce consistent merge commit shas https://review.opendev.org/c/zuul/zuul/+/903911 | ||
| - [zuul/zuul] 904033: DNM: debug reproducible repo state https://review.opendev.org/c/zuul/zuul/+/904033 | ||
| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: [zuul/zuul] 904033: DNM: debug reproducible repo state https://review.opendev.org/c/zuul/zuul/+/904033 | 20:48 | |
| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: [zuul/zuul] 903911: Produce consistent merge commit shas https://review.opendev.org/c/zuul/zuul/+/903911 | 21:38 | |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!