| @fungicide:matrix.org | Blaise Pabon: it doesn't have to be an all-or-nothing approach. many projects leverage multiple ci/cd systems. does https://fedora.softwarefactory-project.io/zuul/projects count as an established project? or https://ci.gerritcodereview.com/t/gerrit/projects maybe? | 00:15 |
|---|---|---|
| @fungicide:matrix.org | Blaise Pabon: the main things that make starting with a new project easier are: 1. no preestablished workflows that developers will resist changing (e.g. being disallowed from merging their own changes or being required to have changes reviewed), and 2. no sunk cost in existing ci/cd configuration which needs to be redone or moved | 00:21 |
| @blaisepabon:matrix.org | What I'm getting at is moving projects that are currently developed using feature branches toward trunk development using patchsets. | 00:22 |
| @fungicide:matrix.org | you mention the cpython project, there was a contentious discussion recently about no longer allowing core devs to merge their own changes | 00:22 |
| @blaisepabon:matrix.org | Oh!! TIL | 00:22 |
| @blaisepabon:matrix.org | and yet... zuul-ci might actually work better for them then. | 00:23 |
| @fungicide:matrix.org | relying on zuul for project gating (well, really relying on anything for project gating) requires buying into some basic precepts like trusting automation to merge your change once it's ready | 00:23 |
| @fungicide:matrix.org | a lot of people in established projects have adverse reactions to what seems to them like giving up control over their development process | 00:25 |
| @blaisepabon:matrix.org | yes, I have seen people bristle when I mention gates | 00:25 |
| @blaisepabon:matrix.org | and yet, none of them want to "break the build" | 00:25 |
| @blaisepabon:matrix.org | so I'm trying to position the gates as "guardrails" | 00:26 |
| @fungicide:matrix.org | also i suppose openstack counts as an established project which moved to using zuul, it was already a pretty big project before zuul existed, and was incrementally moved from jenkins jobs configured in xml files to gradual zuul-by-a-thousand-cuts over some time | 00:27 |
| @blaisepabon:matrix.org | TBH, I have a tendency to be about 5 years ahead of the peak of the adoption curve. | 00:29 |
| What I'm seeing is that open source projects are getting bigger and more dispersed, putting pressure on the original leader (or two) that were carrying the whole thing themselves. | ||
| @fungicide:matrix.org | openstack is the only established project i was personally involved in the move to zuul for, though, so you probably want to hear from a larger variety of people on other projects with more recent experience in that regard | 00:29 |
| @blaisepabon:matrix.org | I suppose using Gerrit is probably a bigger lift than zuul-ci | 00:31 |
| I tend to lump the two together because that was my experience. | ||
| @fungicide:matrix.org | yeah, now zuul supports github, gitlab, pagure... | 00:31 |
| @fungicide:matrix.org | and whatever else someone wants to develop a driver for next | 00:32 |
| @blaisepabon:matrix.org | So maybe my bigger challenge would be to get people to use Gerrit for parts of their repo that they want to make small, frequent changes to. | 00:36 |
| (I'm trying to encourage new contributors and no one likes to see their PR sit un merged for months) | ||
| @fungicide:matrix.org | well, i don't expect gerrit or zuul to solve a lack of reviewer attention. that's endemic to a majority of open source projects in my experience | 00:37 |
| @blaisepabon:matrix.org | I think it's more a question of reducing the merg conflicts that come from old PRs that have small changes. | 00:38 |
| @fungicide:matrix.org | that may help up to a point, but ultimately reviewer attention is a human problem and those are notoriously tough to solve through technological means | 00:39 |
| @blaisepabon:matrix.org | Thanks for helping me think through this, btw | 00:39 |
| @fungicide:matrix.org | my pleasure. hopefully other folks will chime in during their waking hours | 00:40 |
| @jjbeckman:matrix.org | Hello @fungi , thanks so much for taking the time to explain. | 05:57 |
| > only the merged versions of them are used, they can only be used in post-review pipelines, and they can only be used by playbooks that are in the repository they're defined in. also if you have branched configuration, having the same secret defined on multiple branches can behave in ways you may not expect | ||
| I see... | ||
| > Secrets, like most configuration items, are unique within a tenant, though a secret may be defined on multiple branches of the same project as long as the contents are the same. This is to aid in branch maintenance, so that creating a new branch based on an existing branch will not immediately produce a configuration error. | ||
| Now I believe this is what is causing my issue. | ||
| I currently have a `feature/foo` branch where I am testing a certain implementation of a pipeline, with unique Zuul secrets set, and a `feature/bar` branch where I am testing a different implementation with different Zuul secrets set. It appears that Zuul is refering to the secrets in the `feature/foo` branch, even though I'm kicking the pipeline from `feature/bar`. | ||
| Again, thanks a lot for pointing me in the right direction. | ||
| -@gerrit:opendev.org- Simon Westphahl proposed: [zuul/zuul] 890753: Add Zuul event id to merge completed events https://review.opendev.org/c/zuul/zuul/+/890753 | 10:05 | |
| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: [zuul/zuul] 890702: Use tenant-level layout locks https://review.opendev.org/c/zuul/zuul/+/890702 | 23:56 | |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!