| -@gerrit:opendev.org- Zuul merged on behalf of Ian Wienand: | 05:37 | |
| - [zuul/zuul] 838843: ansible zuul_json callback : handle string results https://review.opendev.org/c/zuul/zuul/+/838843 | ||
| - [zuul/zuul] 838971: Add unit test for zuul_json text result parsing https://review.opendev.org/c/zuul/zuul/+/838971 | ||
| -@gerrit:opendev.org- Zuul merged on behalf of Ian Wienand: [zuul/zuul] 839672: zuul_json: remove no_log handling https://review.opendev.org/c/zuul/zuul/+/839672 | 05:37 | |
| -@gerrit:opendev.org- Dominik Jaeger proposed: [zuul/zuul] 828125: Add support for filesets in job configuration https://review.opendev.org/c/zuul/zuul/+/828125 | 08:05 | |
| -@gerrit:opendev.org- Dominik Jaeger proposed: [zuul/zuul] 839550: Add spec for fileset feature https://review.opendev.org/c/zuul/zuul/+/839550 | 10:18 | |
| @jakobmeng:fedora.im | > <@jpew:matrix.org> e.g. when I check `inventory.yaml` in the periodic job, it's still using the old value of the variable | 10:42 |
|---|---|---|
| Hello everyone, we might a similar issue: When we change job.vars, our check jobs still use the old variables. A oneline example that triggers this behavior can be seen in .zuul.yaml here: https://review.opendev.org/c/openstack/ansible-collections-openstack/+/825291 | ||
| @jakobmeng:fedora.im | Any idea what could have caused this or how we can workaround this issue? | 10:42 |
| @jakobmeng:fedora.im | We have actually two branches, master and stable/1.0.0, which might be related | 10:42 |
| @bookwar:fedora.im | Hi, I need help to understand how TLS connection works. When I deploy zookeeper, I generate TLS certs (tls.crt,tls.key, ca.crt) and configure Zookeeper to use them. Then when I deploy nodepool, I have zookeeper-tls config option where I need to specify also tls.crt,tls.key, ca.crt. Are those exactly the same files? Or should I generate another tls.crt and tls.key for the nodepool service? | 11:37 |
| @tristanc_:matrix.org | Aleksandra Fedorova: with https://opendev.org/zuul/zuul/src/branch/master/tools/zk-ca.sh , you can generate certificates per client | 11:48 |
| @jpew:matrix.org | jm1: You end up with multiple job definitions that target the master branch, because that job definition is on multiple branches, but they all target the master branch (via `branches: master`) | 12:44 |
| @jpew:matrix.org | jm1: I'm not sure how Zuul chooses which to use, but it's picking the one from the stable/1.0.0 branch (which is valid because it _targets_ the master branch) and it doesn't have the change you made | 12:46 |
| @jpew:matrix.org | At least, IIUC | 12:47 |
| @jakobmeng:fedora.im | jpew: hmm.. this implies that we cannot have synchronized .zuul.yaml files across branches because Zuul might pick definitions from other branches. | 12:57 |
| @jpew:matrix.org | jm1: If you remove the `branches: master` it will work like you want | 12:58 |
| @jakobmeng:fedora.im | jpew: i cannot remove `branches: master` because this job variant is only for master | 12:59 |
| @jpew:matrix.org | @jm1 Right, so AFAIK there isn't a way to say "this job is only for these branches" (it's not `job.branches` anyway). You can delete the job on the branch copy of .zuul.yaml | 13:00 |
| @jpew:matrix.org | This seems a common misconception.... I suspect some sort of `branches_filter` option in the job would be useful | 13:01 |
| @jakobmeng:fedora.im | jpew: ack, will remove job variants for other branches from .zuul.yaml files and see if that helps. Thanks for helping out! | 13:01 |
| @fungicide:matrix.org | jm1: jpew: the problem generally arises when mixing explicit "branches" matchers with implicit branch matching (from defining the same jobs on multiple branches of a repository). it's generally expected that you'll use one or the other for a job, not both at the same time. the prevailing guidance is to only use "branches" matchers from single-branched projects (e.g. trusted config repos), and when defining jobs in branched repositories you select which version to use by the branch associated wit the triggering event instead | 13:24 |
| @fungicide:matrix.org | * jm1: jpew: the problem typically arises when mixing explicit "branches" matchers with implicit branch matching (from defining the same jobs on multiple branches of a repository). it's generally expected that you'll use one or the other for a job, not both at the same time. the prevailing guidance is to only use "branches" matchers from single-branched projects (e.g. trusted config repos), and when defining jobs in branched repositories you select which version to use by the branch associated wit the triggering event instead | 13:25 |
| @fungicide:matrix.org | * jm1: jpew: the problem typically arises when mixing explicit "branches" matchers with implicit branch matching (from defining the same jobs on multiple branches of a repository). it's generally expected that you'll use one or the other for a job, not both at the same time. the prevailing guidance is to only use "branches" matchers from single-branched projects (e.g. trusted config repos), and when defining jobs in branched repositories you select which version to use by the branch associated with the triggering event instead | 13:26 |
| @jpew:matrix.org | fungi: right. I think there is a use case for restricting the "default" set of jobs you'll get when you make a branch. E.g run these on master, but not on feature branches made from master (unless you specifically edit the job to enable them) | 13:28 |
| @fungicide:matrix.org | which could be accomplished by deleting those job defniitions from the feature branch when you create it, too | 13:29 |
| @jpew:matrix.org | Yes, but then it's a conflict (or just removes them) if you merge back | 13:30 |
| @jakobmeng:fedora.im | jpew: Which is exactly the reason why I wanted to have the same cfg across branches. | 13:39 |
| @jakobmeng:fedora.im | fungi: Could you elaborate on "when defining jobs in branched repositories you select which version to use by the branch associated with the triggering event instead"? How do you select which version to use? | 13:40 |
| @fungicide:matrix.org | the trigger has a branch associated with it, whether it's the branch targeted by the change being proposed, the branch to which a commit merged, a branch attached to a timer trigger... that's the branch name searched across involved projects in order to determine what job configuration should be used | 13:53 |
| @fungicide:matrix.org | inheritance similarly looks for identically-named branches in other repositories (with a default fallback if the same branch name doesn't exist), though there are also configuration options you can use to override or remap branch names in/between projects too | 13:55 |
| @clarkb:matrix.org | to reiterate what fungi was saying earlier you should almost never use the branches: directive on a job which will be copied to multiple branches | 13:58 |
| @clarkb:matrix.org | branches: says "This job applies to this branch" when you have multiple copies of that Zuul has to resolve that somehow and it almost never results in the behavior people want | 13:58 |
| @clarkb:matrix.org | this directive is usefule when you have a single branch config repo and need to apply a version of a job to a specific branch from that config repo. Then maybe you'll have another version of the job for another branch in that config repo | 13:59 |
| @tristanc_:matrix.org | Clark: could we make Zuul job resolution results in the behavior people want? e.g. if the job is defined in a branch, then should it takes the priority over other branches variant featuring a matcher? Or should that be the other way around? | 14:01 |
| @clarkb:matrix.org | tristanC: I think the issue is that some people want one version of behavior and another want another version | 14:02 |
| @clarkb:matrix.org | and since it is ambiguous netiher is more correct than the other | 14:02 |
| @tristanc_:matrix.org | then if it is ambiguous, could we make this situation a config error instead? | 14:04 |
| @jim:acmegating.com | it's not ambiguous, the behavior is precisely described in the documentation. there is absolutely a way to do whichever thing people want. | 14:08 |
| @jpew:matrix.org | corvus: Is there a way to control prevent a job from applying to a branch, while keeping the configuration in the repository where it will get branched? | 14:10 |
| @jpew:matrix.org | * corvus: Is there a way to prevent a job from applying to a branch, while keeping the configuration in the repository where it will get branched? | 14:10 |
| @jim:acmegating.com | jpew: between job.branches and the pragmas, that can be fairly precisely controlled. | 14:12 |
| @tristanc_:matrix.org | When a job is defined in a main branch with a `stable` branch matcher, and if the job is also defined in a stable branch, does Zuul picks the one from the branch (for a change submited on the stable branch) ? | 14:19 |
| @jim:acmegating.com | tristanC: it applies every matching variant | 14:21 |
| @jim:acmegating.com | if the branching logic of a job doesn't match the branching logic of the repo it's in, then you may also want to consider defining the job in a different git repo. | 14:24 |
| @jim:acmegating.com | the general assumption with zuul is that git repos are free, and zuul makes it easy to share work across them. | 14:25 |
| @jim:acmegating.com | (not saying that's the one and only solution here, just another tool that should be considered) | 14:26 |
| @jpew:matrix.org | Sure... but one of the advantages of keeping the config with the code is that you can freely make changes to the configuration on the "master" branch for example without having to worry about breaking the config on a "stable" branch, because that config is "fixed" on that branch and separate. You *can* do this in a separate git repo, but it's harder to deal with and reason about | 14:27 |
| @tristanc_:matrix.org | corvus: ok I see, but what is the use case to mix job defined in different branch, when is this behavior useful? | 14:28 |
| @jim:acmegating.com | jpew: yes indeed, and that's why zuul's job branching behavior default is what it is | 14:28 |
| @jpew:matrix.org | corvus: Right, but I think right now we have to choose: Do we want to have in-repo config where we can't restrict whats included on new branches by default, or a separate repo where we can precisely control everything but it's hard(er) to reason about | 14:31 |
| @jim:acmegating.com | tristanC: it's potentially useful in the case where you want to control the behavior of a job on a different branch from, say, master. one could elect to remove job definitions from other branches and control the whole thing from master. | 14:36 |
| @jim:acmegating.com | (by creating all the per-branch variants in a single file on a single branch) | 14:37 |
| @tristanc_:matrix.org | corvus: I fail to see how controlling the behaviour of a job on a different branch can be useful. What is the advantage compared to changing the job on the desired branch directly? | 14:38 |
| @jim:acmegating.com | tristanC: that's certainly my preference absent other constraining factors, but there are a lot of different ways people want to set up repos | 14:41 |
| @jim:acmegating.com | tristanC: one particular use case is defining a job in an un-branched repo that is used in branched repos | 14:43 |
| @jim:acmegating.com | (ie, the suggestion i made above) | 14:44 |
| @tristanc_:matrix.org | but in that situation, the job is not defined in multiple repos, the branched repos just need to indicate it wants the master^Wmain version of the job right? | 14:46 |
| @tristanc_:matrix.org | it's the mixing definition from multiple branch which I find confusing, and I can't help but wonder why is this the default behavior. | 14:46 |
| @jim:acmegating.com | no, i mean that all the variants are defined in a single file; so it's not about the repo requesting a version, it's about job variants specify what branches they apply to | 14:47 |
| @jim:acmegating.com | it's because the rule is simple: every matching variant applies. if you don't want a variant to apply, delete it or change its branch matcher. | 14:48 |
| @clarkb:matrix.org | > <@jim:acmegating.com> it's not ambiguous, the behavior is precisely described in the documentation. there is absolutely a way to do whichever thing people want. | 14:51 |
| The zuul behavior isn't ambiguous. What the user wants is. We can't just choose a behavior to make jpew's use case work without breaking other users was what I was trying to say. The user's expectation is ambiguous. I agree zuul isn't | ||
| @jpew:matrix.org | FWIW, I do understand that `job.branches` as it is today is useful and doesn't need to change, it just doesn't do the thing I would like.... basically I would like a job variant to be ignored completely if it matches a branch regex | 14:53 |
| @jpew:matrix.org | I feel that is ambiguous, but maybe I'm missing something? | 14:54 |
| @jpew:matrix.org | * I feel that isn't ambiguous, but maybe I'm missing something? | 14:54 |
| @clarkb:matrix.org | jpew: its possibly confusion on my end. I still don't undersatnd why you would need what you are talking about. It seems like you can use the default behavior to have each branch control things. Is the problem that there is a fallback branch and you don't want that to be used? | 14:55 |
| @jpew:matrix.org | Right, so specifically, we have long and expensive "nightly" periodic builds that we want run on our "master" branch and our "stable" branches, but not on every random "feature" branch that gets cut from one of those (usually master). We also really want to keep our config in the repository instead of in a separate repo because it's much easier to maintain that way (for us at least). What I want to do is say "this job will only run if the current branch matches `(master)|(stable/*)` so that the feature branches don't run them every night. However, that's not what `job.branches: master` does; instead it makes multiple variants of the job each time a new branch forks off that all target the `master` branch, and chaos ensues :) | 14:59 |
| @clarkb:matrix.org | jpew: and the feature branches otherwise do want CI for individual changes? Just not periodic pipelines? | 15:00 |
| @jpew:matrix.org | Clark: Right | 15:00 |
| @clarkb:matrix.org | The way I would address that is to remove the jobs from the pipeline in the feature branch | 15:00 |
| @clarkb:matrix.org | that is an explicit representation of what is being requested. It does require an extra commit on each feature branch | 15:01 |
| @jpew:matrix.org | Clark: Right but then you also have to be extra dilligent when you merge back | 15:01 |
| @avass:vassast.org | > <@clarkb:matrix.org> jpew: its possibly confusion on my end. I still don't undersatnd why you would need what you are talking about. It seems like you can use the default behavior to have each branch control things. Is the problem that there is a fallback branch and you don't want that to be used? | 15:02 |
| In my experience some orgs let their users create branches and those users also doesn't manage the CI config. So by making it possible to somehow tell zuul that "this config file/item is only applicable if located on <branch-pattern>" would help those usecases a lot. Is that what `pragma.implied-branches` is for? | ||
| https://www.zuul-ci.org/docs/zuul/latest/config/pragma.html#attr-pragma.implied-branches | ||
| @jpew:matrix.org | > <@avass:vassast.org> In my experience some orgs let their users create branches and those users also doesn't manage the CI config. So by making it possible to somehow tell zuul that "this config file/item is only applicable if located on <branch-pattern>" would help those usecases a lot. Is that what `pragma.implied-branches` is for? | 15:03 |
| > https://www.zuul-ci.org/docs/zuul/latest/config/pragma.html#attr-pragma.implied-branches | ||
| Exactly our use case | ||
| @jim:acmegating.com | > <@jim:acmegating.com> zuul-maint: how do these look for releases: | 15:03 |
| > zuul: commit a89ce345c0fb5fb304713b0b0aa8097312be59f5 (HEAD -> master, tag: 6.0.0, origin/master, gerrit/master, refs/changes/55/840055/1) | ||
| > nodepool: commit a2e5e640ad13b5bf3e7322eb3b62005484e21765 (HEAD -> master, tag: 6.0.0, origin/master, gerrit/master) | ||
| > (if those look good, i'll cut them during my morning tomorrow) | ||
| zuul-maint: ^ ? | ||
| @clarkb:matrix.org | corvus: the shas for both projects lgtm. I don't think nodepool actually had any changes requiring a major verison bump, but I suspect you want to keep nodepool in sync with zuul? lgtm if so | 15:05 |
| @jim:acmegating.com | Clark: yes, (the aws driver changes are significant and arguable, but probably technically not required). same as with v5. | 15:06 |
| @jim:acmegating.com | just seems weird for them not to have the same major number at least. | 15:06 |
| @avass:vassast.org | > <@jim:acmegating.com> just seems weird for them not to have the same major number at least. | 15:06 |
| It helps a lot :) | ||
| @fungicide:matrix.org | yes, we've decided in the past to uprev nodepool's major version component when we do so for zuul | 15:18 |
| @avass:vassast.org | jpew: I started on: https://review.opendev.org/c/zuul/zuul/+/837559 which I had to put it aside because of more important work, but I guess you still want *some* jobs running on those branches? | 15:26 |
| @jpew:matrix.org | Albin Vass: Ya, if that was per-job instead of per-project would cover my case | 15:27 |
| @jim:acmegating.com | i don't think we would want to put job names in the tenant config | 15:28 |
| @jpew:matrix.org | corvus: Ya, sorry. That wasn't what I mean. Make a `job.exclude-branch-pattern` | 15:40 |
| -@gerrit:opendev.org- Clark Boylan proposed: [zuul/zuul] 840356: Bump up to python3.10 https://review.opendev.org/c/zuul/zuul/+/840356 | 16:34 | |
| @clarkb:matrix.org | Note I don't think ^ is urgent, but Zuul is a test platform I'm reasonably familiar with so using it as a sanity check for the new jammy images and python3.10 base docker images is helpful for me. | 16:35 |
| -@gerrit:opendev.org- Clark Boylan proposed: [zuul/zuul] 840356: Bump up to python3.10 https://review.opendev.org/c/zuul/zuul/+/840356 | 16:40 | |
| -@gerrit:opendev.org- Clark Boylan proposed: [zuul/zuul] 840356: Bump up to python3.10 https://review.opendev.org/c/zuul/zuul/+/840356 | 16:54 | |
| @jim:acmegating.com | pushed 6.0.0 (both) | 16:58 |
| -@gerrit:opendev.org- Clark Boylan proposed: [zuul/zuul] 840356: Bump up to python3.10 https://review.opendev.org/c/zuul/zuul/+/840356 | 17:06 | |
| -@gerrit:opendev.org- Clark Boylan proposed: [zuul/zuul] 840356: Bump up to python3.10 https://review.opendev.org/c/zuul/zuul/+/840356 | 17:13 | |
| -@gerrit:opendev.org- Clark Boylan proposed: [zuul/zuul] 840356: Bump up to python3.10 https://review.opendev.org/c/zuul/zuul/+/840356 | 17:20 | |
| @clarkb:matrix.org | Already catching some interesting stuff like python_version needing to be a string because 3.1 == 3.10 when a float | 17:20 |
| @clarkb:matrix.org | python cryptography is spamming about blowfish being deprecated when using paramiko. Paramiko has changes to fix this but won't make a quick release to address it. Cryptography can be pinned < 37 to drop the warnings but that seems less ideal than just accepting warnings for a bit | 17:47 |
| @jim:acmegating.com | yeah i linked to those last week | 18:00 |
| @jim:acmegating.com | https://github.com/paramiko/paramiko/pull/2039 | 18:01 |
| @clarkb:matrix.org | corvus: thanks. Also, will there be emailed release notices soon? I'm trying to get the newsletter content together and will include that for zuul and nodepool | 18:05 |
| @jim:acmegating.com | Clark: nodepool's not done yet, but soon i hope | 18:08 |
| @jim:acmegating.com | now nodepool is done. :) | 18:08 |
| @clarkb:matrix.org | oh right nodepool image builds take a bit of time | 18:13 |
| @jim:acmegating.com | emails sent | 18:19 |
| @jpew:matrix.org | fungi: Cool, I got the SMTP -> Teams channel filters working (although the formatting options for the SMTP subject leave a little be be desired), thanks for the help! | 18:20 |
| @jakobmeng:fedora.im | > <@fungicide:matrix.org> the trigger has a branch associated with it, whether it's the branch targeted by the change being proposed, the branch to which a commit merged, a branch attached to a timer trigger... that's the branch name searched across involved projects in order to determine what job configuration should be used | 18:23 |
| Thanks for the clarification! | ||
| -@gerrit:opendev.org- Clark Boylan proposed: [zuul/zuul] 840356: Bump up to python3.10 https://review.opendev.org/c/zuul/zuul/+/840356 | 18:37 | |
| @jakobmeng:fedora.im | > <@jim:acmegating.com> it's not ambiguous, the behavior is precisely described in the documentation. there is absolutely a way to do whichever thing people want. | 18:43 |
| "precisely described" might be a bit far stretched 😉 I spent two weeks reading Zuul's docs and source code, committed dozens of .zuul.yaml patches and did a lot of trial & error to set up something as simple as running slightly different jobs for two branches. Everything worked as expected.. until we submitted a change for a check job on master branch which was simply ignored. Why? "One shall not use identical job definitions with `branches: master` across multiple branches". Which i did because i wanted to keep a identical `.zuul.yaml` across all branches because (a) less merge conflicts when changing `.zuul.yaml` and (b) increase visibility because one finds all jobs in a single `.zuul.yaml`. | ||
| @clarkb:matrix.org | one method for making git merging less painful would be to `git checkout --ours -- .zuul.yaml` after conflict | 18:52 |
| @clarkb:matrix.org | it is an extra step though, but should be straightforward to decide which version you want without needing to manually resolve anything | 18:53 |
| -@gerrit:opendev.org- Dr. Jens Harbott proposed: [zuul/zuul-sphinx] 840366: Avoid infinite loop in find_zuul_yaml() https://review.opendev.org/c/zuul/zuul-sphinx/+/840366 | 18:54 | |
| @jakobmeng:fedora.im | > <@clarkb:matrix.org> one method for making git merging less painful would be to `git checkout --ours -- .zuul.yaml` after conflict | 18:56 |
| Thanks for this tip! Resolving merge conflicts is not an issue most of the time. I just wanted to point out that I had reasons for my initial approach of a single `.zuul.yaml`. But i am fine with different files if my approach is currently not possible. | ||
| @jim:acmegating.com | jm1: i'm sorry the docs didn't meet your needs, but i'm glad you got the info you needed in the end. | 18:56 |
| @jim:acmegating.com | it does sound like zuul's default behavior is pretty close to what you want aside from the git merge issue | 18:57 |
| @jakobmeng:fedora.im | > <@jim:acmegating.com> it does sound like zuul's default behavior is pretty close to what you want aside from the git merge issue | 18:58 |
| Yes. I would have saved me a headache if i had not tried to go for a single `.zuul.yaml` 😅 | ||
| @q:fricklercloud.de | the tox pep8 check on zuul-sphinx seems to be pretty broken, but it also isn't run by the CI, so maybe no surprise? | 19:04 |
| @jakobmeng:fedora.im | > <@fungicide:matrix.org> inheritance similarly looks for identically-named branches in other repositories (with a default fallback if the same branch name doesn't exist), though there are also configuration options you can use to override or remap branch names in/between projects too | 19:07 |
| This "default fallback" hit me hard [1] because sometimes there is no default fallback: When a patch is submitted against a branch, Zuul CI will collect job variants for each ci job and all its parent jobs. If both `job.override-checkout` and `job.required-projects.override-checkout` attributes are not defined, then Zuul will for each (parent) job match the current branch of the patch against all branches of the project in which the job is defined. If no such branch exist in a project, then no job variant matches and this job will be ignored [2]. For example, if a patch is submitted for our `stable/1.0.0` branch, then Zuul CI will try to match `stable/1.0.0` against all branches in the projects where job `ansible-collections-openstack-functional-devstack` and its parent job `openstacksdk-functional-devstack` are defined. The first is defined in `openstack/ansible-collections-openstack/.zuul.yaml`, so a match for `stable/1.0.0` will be found. But `openstacksdk-functional-devstack` is defined in `openstack/openstacksdk/.zuul.yaml` which has no branch `stable/1.0.0` defined. So Zuul will not schedule `job ansible-collections-openstack-functional-devstack` at all. Please correct me if i am wrong 🙈 | ||
| Ref.: | ||
| [1] https://opendev.org/openstack/ansible-collections-openstack/commit/e2ee2d0f5df3ff4daafb6dfc9936bff3f121dac5 | ||
| [2] https://opendev.org/zuul/zuul/src/branch/master/zuul/model.py#L6996 | ||
| @jakobmeng:fedora.im | > <@fungicide:matrix.org> inheritance similarly looks for identically-named branches in other repositories (with a default fallback if the same branch name doesn't exist), though there are also configuration options you can use to override or remap branch names in/between projects too | 19:09 |
| * This "default fallback" hit me hard \[1\] because sometimes there is no default fallback: When a patch is submitted against a branch, Zuul CI will collect job variants for each ci job and all its parent jobs. If both `job.override-checkout` and `job.required-projects.override-checkout` attributes are not defined, then Zuul will for each (parent) job match the current branch of the patch against all branches of the project in which the job is defined. If no such branch exist in a project, then no job variant matches and this job will be ignored \[2\]. For example, if a patch is submitted for our `stable/1.0.0` branch, then Zuul CI will try to match `stable/1.0.0` against all branches in the projects where job `ansible-collections-openstack-functional-devstack` and its parent job `openstacksdk-functional-devstack` are defined. The first is defined in `openstack/ansible-collections-openstack/.zuul.yaml`, so a match for `stable/1.0.0` will be found. But `openstacksdk-functional-devstack` is defined in `openstack/openstacksdk/.zuul.yaml` which has no branch `stable/1.0.0` defined. So Zuul will not schedule `job ansible-collections-openstack-functional-devstack` at all. Please correct me if i am wrong 🙈 | ||
| Ref.: | ||
| \[1\] https://opendev.org/openstack/ansible-collections-openstack/commit/e2ee2d0f5df3ff4daafb6dfc9936bff3f121dac5 | ||
| \[2\] https://opendev.org/zuul/zuul/src/branch/master/zuul/model.py | ||
| @jakobmeng:fedora.im | * This "default fallback" hit me hard \[1\] because sometimes there is no default fallback: When a patch is submitted against a branch, Zuul CI will collect job variants for each ci job and all its parent jobs. If both `job.override-checkout` and `job.required-projects.override-checkout` attributes are not defined, then Zuul will for each (parent) job match the current branch of the patch against all branches of the project in which the job is defined. If no such branch exist in a project, then no job variant matches and this job will be ignored \[2\]. For example, if a patch is submitted for our `stable/1.0.0` branch, then Zuul CI will try to match `stable/1.0.0` against all branches in the projects where job `ansible-collections-openstack-functional-devstack` and its parent job `openstacksdk-functional-devstack` are defined. The first is defined in `openstack/ansible-collections-openstack/.zuul.yaml`, so a match for `stable/1.0.0` will be found. But `openstacksdk-functional-devstack` is defined in `openstack/openstacksdk/.zuul.yaml` which has no branch `stable/1.0.0` defined. So Zuul will not schedule `job ansible-collections-openstack-functional-devstack` at all. Please correct me if i am wrong 🙈 | 19:16 |
| Ref.: | ||
| \[1\] https://opendev.org/openstack/ansible-collections-openstack/commit/e2ee2d0f5df3ff4daafb6dfc9936bff3f121dac5 | ||
| \[2\] https://opendev.org/zuul/zuul/src/branch/master/zuul/model.py#L7126 | ||
| @fungicide:matrix.org | jm1: the "default fallback" i was referring to is usually the "master" branch but can be changed by setting project.default-branch: https://zuul-ci.org/docs/zuul/latest/job-content.html#git-repositories https://zuul-ci.org/docs/zuul/latest/config/project.html#attr-project.default-branch | 20:42 |
| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: [zuul/zuul] 840381: Update docs to clarify inheritance and global repo state https://review.opendev.org/c/zuul/zuul/+/840381 | 20:48 | |
| -@gerrit:opendev.org- Joshua Watt proposed: [zuul/zuul] 840388: Add feature to exclude jobs based on branch https://review.opendev.org/c/zuul/zuul/+/840388 | 22:09 | |
| @jpew:matrix.org | Ok, this https://review.opendev.org/c/zuul/zuul/+/840388 is basically what I'm talking about. Still needs tests/documentation/etc but is the idea sound? | 22:09 |
| -@gerrit:opendev.org- Ian Wienand proposed: [zuul/nodepool] 840395: dib: bump to 3.21.0 https://review.opendev.org/c/zuul/nodepool/+/840395 | 23:44 | |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!