| @iwienand:matrix.org | fungi: https://review.opendev.org/c/zuul/zuul-jobs/+/840566 was one that came up from the deb building. after debsign dput seems to like to check the signatures | 00:19 |
|---|---|---|
| @iwienand:matrix.org | so we need to trust the key we imported (well, it still seems to work, but puts out errors) | 00:19 |
| @d-j-j:matrix.org | > <@jim:acmegating.com> d-j-j: we don't want to switch for performance reasons, but rather safety from user input. it's not a drop in replacement; it has significant functional shortcomings compared to the standard re library, including features people currently use with file matchers (especially around negative lookaheads). that's why it needs careful thought as to how it interacts with the proposal. | 07:38 |
| Thank you for clarifying. I read about the shortcomings but it says also "the module will automatically fall back to the original re module if there is a regex that it cannot handle.". | ||
| There is also a possibility to configure a fallback notification in the form of a warning. | ||
| Are there reasons to believe that this fallback mechanism wouldn't work or it should be generally avoided or even prohibited? | ||
| I'm not sure if we should mix the re2 switch with the fileset proposal. | ||
| I don't see a technical necessity to do both at the same time. | ||
| Currently file matchers still use standard re module and so could fileset. | ||
| An advantage of doing it at the same time could be that users would only have to check their configurations once for both migrations. | ||
| But then probably we should also switch to re2 for other regexes in the configuration like for example branch matchers. | ||
| Should we then combine both topics in one big spec: fileset + switching whole zuul config to re2? | ||
| -@gerrit:opendev.org- Dominik Jaeger proposed: [zuul/zuul] 839550: Add spec for fileset feature https://review.opendev.org/c/zuul/zuul/+/839550 | 09:58 | |
| @d-j-j:matrix.org | > <@jim:acmegating.com> d-j-j: we don't want to switch for performance reasons, but rather safety from user input. it's not a drop in replacement; it has significant functional shortcomings compared to the standard re library, including features people currently use with file matchers (especially around negative lookaheads). that's why it needs careful thought as to how it interacts with the proposal. | 09:59 |
| * Thank you for clarifying. I read about the shortcomings but it says also "the module will automatically fall back to the original re module if there is a regex that it cannot handle.". | ||
| There is also a possibility to configure a fallback notification in the form of a warning. | ||
| Are there reasons to believe that this fallback mechanism wouldn't work or it should be generally avoided or even prohibited? | ||
| I'm not sure if we should mix the re2 switch with the fileset proposal. | ||
| I don't see a technical necessity to do both at the same time. | ||
| Currently file matchers still use standard re module and so could fileset. | ||
| An advantage of doing it at the same time could be that users would only have to check their configurations once for both migrations. | ||
| But then probably we should also switch to re2 for other regexes in the configuration like for example branch matchers. | ||
| Should we then combine both topics in one big spec: fileset + switching whole zuul config to re2? | ||
| (Unfortunately I won't be able to respond until Monday) | ||
| @dpawlik:matrix.org | Hello folks, could you check https://review.opendev.org/c/zuul/zuul/+/840679/ when free time? | 10:00 |
| @dpawlik:matrix.org | tl;dr Ansible returns "*0" with rc 0 when passlib is not installed when used an Ansible function password_hash('bcrypt', rounds=12) | 10:01 |
| @avass:vassast.org | I think it's a bit misleading to configure 'trigger.approval` for gerrit connections. After reading the gerrit docs it sounds like all approvals set on the change are included in all comment-added events, not only approvals set by the action reported by the event: https://gerrit-review.googlesource.com/Documentation/json.html#approval | 10:19 |
| We ended up in a situation where zuul got stuck in an infinite loop because we configured zuul to not report `Verified: -2` on merge failures, and the merge-failure comment then re-triggered the pipeline (because it would trigger on any comment, as long as the labels were set, like a requirement and not a trigger). I added a negative lookahead that matches `Merge Failure.` comments as a quickfix for now. | ||
| @avass:vassast.org | Theres a `vote-deleted` event but not a `vote-added` :( | 10:20 |
| https://gerrit-review.googlesource.com/Documentation/cmd-stream-events.html#_vote_deleted | ||
| @avass:vassast.org | * I think it's a bit misleading to configure 'trigger.approval\` for gerrit connections. After reading the gerrit docs it sounds like all approvals set on the change are included in all comment-added events, not only approvals set by the action reported by the event: https://gerrit-review.googlesource.com/Documentation/cmd-stream-events.html#_comment_added | 10:22 |
| We ended up in a situation where zuul got stuck in an infinite loop because we configured zuul to not report `Verified: -2` on merge failures, and the merge-failure comment then re-triggered the pipeline (because it would trigger on any comment, as long as the labels were set, like a requirement and not a trigger). I added a negative lookahead that matches `Merge Failure.` comments as a quickfix for now. | ||
| @clarkb:matrix.org | Albin Vass: why did it loop and not eventually merge? At least my first thought is it should retry and then in theory if approved eventually succeed? | 13:22 |
| @avass:vassast.org | Clark: the change itself had a merge failure | 13:23 |
| @clarkb:matrix.org | Fwiw the Gerrit behavior you describe is a result of them "fixing" not sending vote values on new comments if they are duplicates. For example if I send +2 twice only the first would have a +2 in the past. But then they "fixed" it by sending all values all the time iirc rather than just sending the +2 each time | 13:24 |
| @avass:vassast.org | that seems more liking a different kind of bug instead... | 13:24 |
| @avass:vassast.org | * that seems more like a different kind of bug instead...e | 13:24 |
| @avass:vassast.org | * that seems more like a different kind of bug instead... | 13:25 |
| @clarkb:matrix.org | > <@avass:vassast.org> Clark: the change itself had a merge failure | 13:25 |
| And I guess reviewers didn't know they needed to -2 to break the cycle? | ||
| @avass:vassast.org | yeah | 13:25 |
| @clarkb:matrix.org | > <@avass:vassast.org> that seems more like a different kind of bug instead... | 13:25 |
| Sure but we didn't have control over how Gerrit fixed it. This was years ago | ||
| @avass:vassast.org | we configured zuul to not report -2 for merge failures because we're still running v2 for a repo, but connected v6 to that one to start testing jobs. So if the repo would get a merge failure in v6 but not v2 it would get completely blocked. | 13:27 |
| @clarkb:matrix.org | IMO if a comment is recieved and the change is approved the correct thing for zuul to do is process that approval. If zuul doesn't do that then you end up needing to construct additional trigger mechanisms. | 13:28 |
| @clarkb:matrix.org | > <@avass:vassast.org> we configured zuul to not report -2 for merge failures because we're still running v2 for a repo, but connected v6 to that one to start testing jobs. So if the repo would get a merge failure in v6 but not v2 it would get completely blocked. | 13:28 |
| You should only have one gating system though? | ||
| @avass:vassast.org | > <@clarkb:matrix.org> You should only have one gating system though? | 13:28 |
| yep | ||
| @avass:vassast.org | > <@clarkb:matrix.org> IMO if a comment is recieved and the change is approved the correct thing for zuul to do is process that approval. If zuul doesn't do that then you end up needing to construct additional trigger mechanisms. | 13:29 |
| yeah, but that makes the "Approval" part work more like a "require" config and not a "trigger" (because of gerrits behaviour). | ||
| @avass:vassast.org | the trigger is technically *any comment* | 13:30 |
| @clarkb:matrix.org | Sure. I find that behavior better than forcing people to unapprove then approve things when the state is already present and just needs to be processed | 13:31 |
| @avass:vassast.org | > <@clarkb:matrix.org> Sure. I find that behavior better than forcing people to unapprove then approve things when the state is already present and just needs to be processed | 13:32 |
| but we have different triggers for recheck/regate(reverify), and just require the correct approvals | ||
| @clarkb:matrix.org | The Gerrit checks plugin stuff may make this a bit more intuitive as it can directly trigger things without relying on comments | 13:32 |
| @jpew:matrix.org | In our gerrit (3.1.12) it only appears to send the approval state for the user that submitted the comment (not all of them); did this change after that? | 13:32 |
| @clarkb:matrix.org | But that requires writing a plugin that understands the zuul api | 13:32 |
| @avass:vassast.org | I'm just saying that adding approvals to triggers is misleading because that's not the actual behavious | 13:33 |
| @avass:vassast.org | * I'm just saying that adding approvals to triggers is misleading because that's not the actual behaviour | 13:33 |
| @avass:vassast.org | let me send you an example | 13:33 |
| @clarkb:matrix.org | > <@jpew:matrix.org> In our gerrit (3.1.12) it only appears to send the approval state for the user that submitted the comment (not all of them); did this change after that? | 13:34 |
| I'd have to go test it against our 3.4 install to know the exact behavior. There were some changes around this around Gerrit 3.3 iirc | ||
| @avass:vassast.org | The first example is what we configured, the second example is the behaviour we see: | 13:36 |
| ``` | ||
| require: | ||
| gerrit: | ||
| open: True | ||
| current-patchset: True | ||
| approval: | ||
| - Code-Review: 2 | ||
| - Verified: [1, -2] | ||
| trigger: | ||
| gerrit: | ||
| - event: comment-added | ||
| approval: | ||
| - Code-Review: 2 | ||
| - event: comment-added | ||
| approval: | ||
| - Verified: 1 | ||
| - event: comment-added | ||
| comment: (?i)^(Patch Set [0-9]+:)?( [\w\\+-]*)*(\n\n)?\s*regate | ||
| --- | ||
| require: | ||
| gerrit: | ||
| open: True | ||
| current-patchset: True | ||
| approval: | ||
| - Code-Review: 2 | ||
| - Verified: [1, -2] | ||
| trigger: | ||
| gerrit: | ||
| - event: comment-added | ||
| ``` | ||
| @avass:vassast.org | * The first example is what we configured, the second example is the behaviour we see: | 13:37 |
| ``` | ||
| require: | ||
| gerrit: | ||
| open: True | ||
| current-patchset: True | ||
| approval: | ||
| - Code-Review: 2 | ||
| - Verified: [1, -2] | ||
| trigger: | ||
| gerrit: | ||
| - event: comment-added | ||
| approval: | ||
| - Code-Review: 2 | ||
| - event: comment-added | ||
| approval: | ||
| - Verified: 1 | ||
| - event: comment-added | ||
| comment: (?i)^(Patch Set [0-9]+:)?( [\w\\+-]*)*(\n\n)?\s*regate | ||
| --- | ||
| require: | ||
| gerrit: | ||
| open: True | ||
| current-patchset: True | ||
| approval: | ||
| - Code-Review: 2 | ||
| - Verified: [1, -2] | ||
| trigger: | ||
| gerrit: | ||
| - event: comment-added | ||
| ``` | ||
| @avass:vassast.org | So for most cases we want the gate pipeline to start whenever CR+2,V+1 is set. But in this case we configured zuul to not report V-2 on merge failure, and thought that would be fine since the comment from zuul should't trigger a rerun (but it does). That happens because the trigger.approval config practically doesn't do anything as far as I can see, so the attribute is misleading | 13:40 |
| @clarkb:matrix.org | https://bugs.chromium.org/p/gerrit/issues/detail?id=13800 is the Gerrit 3.3 change I'm thinking of which is comment content related not vote related | 13:42 |
| @clarkb:matrix.org | Albin Vass: it's meant to filter the content of the comment votes. But if you have a prior +2 and comment again without removing your +2 that is treated as a new +2 | 13:43 |
| @clarkb:matrix.org | This is because forcing people to add a bunch of state toggle comments is bad UX in gerrit | 13:44 |
| @clarkb:matrix.org | And at least 3.1.12 will only report your votes when you comment. Need to look at other gerrits to see if that is consistent | 13:45 |
| @fungicide:matrix.org | > <@iwienand:matrix.org> so we need to trust the key we imported (well, it still seems to work, but puts out errors) | 14:44 |
| what's the exact error look like? gpg emits warnings pretty much any time you do anything with a key which isn't marked as trusted, which i find annoying, but that's usually non-fatal | ||
| -@gerrit:opendev.org- Clark Boylan proposed: | 15:53 | |
| - [zuul/zuul-website] 840951: Use relative paths in docs/index.html https://review.opendev.org/c/zuul/zuul-website/+/840951 | ||
| - [zuul/zuul-website] 840952: Add a Blog system to the zuul website https://review.opendev.org/c/zuul/zuul-website/+/840952 | ||
| @y2kenny:matrix.org | quick question on nodepool 6.0, is it backward compatible with 5.x? (can it be upgraded independently of the rest of zuul?) | 16:18 |
| @fungicide:matrix.org | Kenny Ho: yes, the only reason it wasn't 5.1.0 was in order to realign the major version number with zuul. other than following the upgrade recommendations in https://zuul-ci.org/docs/nodepool/6.0.0/releasenotes.html#relnotes-6-0-0 it shouldn't matter which you upgrade first | 16:23 |
| @clarkb:matrix.org | Albin Vass: jpew ok ya on 3.4 I only see the approvals I've made not other users. But since Gerrit doesn't distingusi between leaving approvals and ocmmenting if I make a second commit without modifying my older +2 to something else it shows me a +2. I think that is correct given how Gerrit doesn't split the approvals from the comments. Albin Vass is it possible that your users kept leaving +2 comments when they should've removed the +2 due to the failures? | 16:46 |
| @clarkb:matrix.org | tristanC: or anyone else that groks the react in zuul-web review on https://review.opendev.org/c/zuul/zuul/+/840769 would be appreciated as that is expected to fix the scroll to log file highlight issue | 16:53 |
| @fungicide:matrix.org | ianw: nevermind, i found it in the promote build results from the referenced ozj change: https://zuul.opendev.org/t/openstack/build/e64411fd73134f20b02250cf5726454f/log/job-output.txt#405-406 | 16:53 |
| -@gerrit:opendev.org- Jeremy Stanley https://matrix.to/#/@fungicide:matrix.org proposed wip: | 18:44 | |
| - [zuul/zuul-website] 840978: Draft an initial blog article https://review.opendev.org/c/zuul/zuul-website/+/840978 | ||
| - [zuul/zuul-website] 840979: DNM: Add a Lorem Ipsum article https://review.opendev.org/c/zuul/zuul-website/+/840979 | ||
| @avass:vassast.org | Clark: | 18:52 |
| > Albin Vass is it possible that your users kept leaving +2 comments when they should've removed the +2 due to the failures? | ||
| Probably, I don't think they were actively monitoring the change. | ||
| > But since Gerrit doesn't distingusi between leaving approvals and ocmmenting if I make a second commit without modifying my older +2 to something else it shows me a +2. I think that is correct given how Gerrit doesn't split the approvals from the comments. | ||
| That is an issue to me since the event includes information about approvals even though nothing was changed there. It's like it's sending information about the state of the change, rather than what was changed. Which means it's not possible to 'edge trigger' when a user toggles a label. I don't see that as an issue in the users workflow or an issue in zuul. Just a very strange design decision taken by gerrit. | ||
| I think the reason that it looped was that zuul had already given a +1, so it matched the requirements, and since it didn't -2 when it failed to merge or removed the label when it started it kept triggering the gate pipeline with the `Merge failed` comment. | ||
| @avass:vassast.org | * Clark: | 18:52 |
| > Albin Vass is it possible that your users kept leaving +2 comments when they should've removed the +2 due to the failures? | ||
| Probably, I don't think they were actively monitoring the change. | ||
| > But since Gerrit doesn't distingusi between leaving approvals and ocmmenting if I make a second commit without modifying my older +2 to something else it shows me a +2. I think that is correct given how Gerrit doesn't split the approvals from the comments. | ||
| > That is an issue to me since the event includes information about approvals even though nothing was changed there. It's like it's sending information about the state of the change, rather than what was changed. Which means it's not possible to 'edge trigger' when a user toggles a label. I don't see that as an issue in the users workflow or an issue in zuul. Just a very strange design decision taken by gerrit. | ||
| I think the reason that it looped was that zuul had already given a +1, so it matched the requirements, and since it didn't -2 when it failed to merge or removed the label when it started it kept triggering the gate pipeline with the `Merge failed` comment. | ||
| @avass:vassast.org | * Clark: | 18:52 |
| > Albin Vass is it possible that your users kept leaving +2 comments when they should've removed the +2 due to the failures? | ||
| Probably, I don't think they were actively monitoring the change. | ||
| > But since Gerrit doesn't distingusi between leaving approvals and ocmmenting if I make a second commit without modifying my older +2 to something else it shows me a +2. I think that is correct given how Gerrit doesn't split the approvals from the comments. | ||
| That is an issue to me since the event includes information about approvals even though nothing was changed there. It's like it's sending information about the state of the change, rather than what was changed. Which means it's not possible to 'edge trigger' when a user toggles a label. I don't see that as an issue in the users workflow or an issue in zuul. Just a very strange design decision taken by gerrit. | ||
| I think the reason that it looped was that zuul had already given a +1, so it matched the requirements, and since it didn't -2 when it failed to merge or removed the label when it started it kept triggering the gate pipeline with the `Merge failed` comment. | ||
| @avass:vassast.org | Seems to me that there should exist a `vote-added` in addition to the `vote-deleted` event in gerrit | 18:54 |
| -@gerrit:opendev.org- Zuul merged on behalf of Clark Boylan: [zuul/zuul] 840769: Set logfile isFetching initial state to true https://review.opendev.org/c/zuul/zuul/+/840769 | 18:54 | |
| @avass:vassast.org | we can live with it for now until we've migrated everything to v6 in any case, and then we can start setting V-2 on merge failures again. | 18:55 |
| @avass:vassast.org | corvus d-j-j ^ I used a negative lookahead as a quickfix to work around that, I'm not sure if it's relevant to the re2 discussion I saw the other day but I believe negative lookaheads aren't supported by re2 :) | 18:58 |
| @clarkb:matrix.org | > <@avass:vassast.org> Clark: | 18:59 |
| > | ||
| > > Albin Vass is it possible that your users kept leaving +2 comments when they should've removed the +2 due to the failures? | ||
| > | ||
| > Probably, I don't think they were actively monitoring the change. | ||
| > | ||
| > > But since Gerrit doesn't distingusi between leaving approvals and ocmmenting if I make a second commit without modifying my older +2 to something else it shows me a +2. I think that is correct given how Gerrit doesn't split the approvals from the comments. | ||
| > | ||
| > That is an issue to me since the event includes information about approvals even though nothing was changed there. It's like it's sending information about the state of the change, rather than what was changed. Which means it's not possible to 'edge trigger' when a user toggles a label. I don't see that as an issue in the users workflow or an issue in zuul. Just a very strange design decision taken by gerrit. | ||
| > | ||
| > I think the reason that it looped was that zuul had already given a +1, so it matched the requirements, and since it didn't -2 when it failed to merge or removed the label when it started it kept triggering the gate pipeline with the `Merge failed` comment. | ||
| But thats the thing with how Gerrit fundamentally works. Every time you leave a comment you also leave a vote. You cannot leave a comment without leaving a vote. It may be that the vot eis the same as before but its still selected as a +2 or whateve rand posted with the comment | ||
| @clarkb:matrix.org | If Gerrit changed the UI (and probably APIs?) to separate the two then you could have what you want but that currently isn't possible | 18:59 |
| -@gerrit:opendev.org- Jeremy Stanley https://matrix.to/#/@fungicide:matrix.org proposed wip: | 19:01 | |
| - [zuul/zuul-website] 840978: Draft an initial blog article https://review.opendev.org/c/zuul/zuul-website/+/840978 | ||
| - [zuul/zuul-website] 840979: DNM: Add a Lorem Ipsum article https://review.opendev.org/c/zuul/zuul-website/+/840979 | ||
| -@gerrit:opendev.org- Jeremy Stanley https://matrix.to/#/@fungicide:matrix.org proposed on behalf of Clark Boylan: [zuul/zuul-website] 840952: Add a Blog system to the zuul website https://review.opendev.org/c/zuul/zuul-website/+/840952 | 19:01 | |
| -@gerrit:opendev.org- Jeremy Stanley https://matrix.to/#/@fungicide:matrix.org proposed: [zuul/zuul-website] 840980: Style heading levels 4-6 https://review.opendev.org/c/zuul/zuul-website/+/840980 | 19:01 | |
| @clarkb:matrix.org | Looks like maybe the API does already separate them so it is mostly a UI thing? | 19:01 |
| @avass:vassast.org | > <@clarkb:matrix.org> But thats the thing with how Gerrit fundamentally works. Every time you leave a comment you also leave a vote. You cannot leave a comment without leaving a vote. It may be that the vot eis the same as before but its still selected as a +2 or whateve rand posted with the comment | 19:02 |
| sure, I just think it's a very strange decision to force every comment to send a vote, even if it was left with the same value | ||
| @avass:vassast.org | like, if you send another comment the user doesn't need to take an active decision to leave it as it was. | 19:03 |
| @clarkb:matrix.org | Albin Vass: because when you leave a comment in Gerrit the +2 is still checked, You are posting a +2 | 19:04 |
| @clarkb:matrix.org | if you didn't want to you can change it to a 0 or something else | 19:04 |
| @clarkb:matrix.org | I understand what you are saying but I'm trying to explain why it doesn't really work with the way Gerrit (the UI at least) seems to function | 19:04 |
| @clarkb:matrix.org | Under that system if you want what yo uare describing you have t odelete your vote then add it again later anyway | 19:05 |
| @clarkb:matrix.org | so its not really an improvement. The improvement has to come from changing the way you post votes in the first place I think | 19:05 |
| @clarkb:matrix.org | what github does is separate label posting and comments entirely aiui | 19:06 |
| @clarkb:matrix.org | whereas gerrit tightly couples them. That causes the confusion | 19:06 |
| @clarkb:matrix.org | as a user it is pretty terrible to have to delete your +A vote. Then leave another comment to add a +A vote when you want to reapprove something. If we could post comments without any implied vote context and separate say "I'm reapplying a +A" then I think it would address your concerns but gerrit just doesn do that (at least via the web UI) | 19:08 |
| @clarkb:matrix.org | fungi: left a minor thing on your draft, but that is looking like a thing that might actually work | 19:12 |
| @avass:vassast.org | To me it seems worse that you cannot comment without setting approvals | 19:12 |
| @clarkb:matrix.org | > <@avass:vassast.org> To me it seems worse that you cannot comment without setting approvals | 19:13 |
| You can but you have to explicitly remove them (since by default it carries them over) | ||
| @clarkb:matrix.org | and to me that makes sense with the current tooling. If I leave a comment and +2 is still selected and post that I expect +2 events to occur | 19:13 |
| @clarkb:matrix.org | if I didn't want +2 events to occur I can swithc it to another value | 19:13 |
| @clarkb:matrix.org | and I do think it is a bit hacky given how gerrit works. But in theory if someone writes a gerrit checks plugin for zuul that can be corrected via native ui elements | 19:15 |
| @avass:vassast.org | I don't know, it seems like a sever limitation to me. We just wanted to send information back to the user, without changing approvals or triggering any third party systems, and that just isn't supported by gerrit in this case because of that. | 19:16 |
| @avass:vassast.org | * I don't know, it seems like a severe limitation to me. We just wanted to send information back to the user, without changing approvals or triggering any third party systems, and that just isn't supported by gerrit in this case because of that. | 19:16 |
| @clarkb:matrix.org | though I'm not sure if it can hook into the votes system to do the triggering rather than zuul still needingto interpret events | 19:16 |
| @clarkb:matrix.org | > <@avass:vassast.org> I don't know, it seems like a severe limitation to me. We just wanted to send information back to the user, without changing approvals or triggering any third party systems, and that just isn't supported by gerrit in this case because of that. | 19:18 |
| I may not be fully understanding the situation you describe or maybe there is a specific version of software that behaves differently. But if you posted a comment +1 from zuul that should only trigger jobs if you trigger on a +1 from zuul. I've sort of keyed on the +2 code revie wbecaues your examples showed that and I would expect that form humans who can choose to remove the +2 if they know the code is broken | ||
| @clarkb:matrix.org | But based on what jpew reported and what I saw with Gerrit 3.4 it should only include the approvals for the user that commented | 19:18 |
| @clarkb:matrix.org | which means if your zuul comments +1 it would get back +1 verified and check for triggers on that | 19:18 |
| @avass:vassast.org | Clark: I guess the issue is that we were reusing the same `zuul` user for v2 and v6 | 19:18 |
| @clarkb:matrix.org | oh ya I wouldn't do that because zuul does internal actions on its own events iirc | 19:19 |
| @avass:vassast.org | but I don't think that would have solved in anyhow now that I think. Since it got triggered by it's own `Merge failure` comment that didn't change any approvals, just to be sure it wouldn't affect the project that was still using v2, which means it would still trigger itself for projects that were using v6 whenever it got a merge failure. | 19:23 |
| @clarkb:matrix.org | I'm guessing you have a trigger that looks for a +1 Verified and a +2 code-review to enqueue change sthat have newly finished checking and are approved to the gate | 19:24 |
| @avass:vassast.org | that makes it a bit harder to migrate projects to v6 from v2 | 19:24 |
| @clarkb:matrix.org | that wasn't in your example I don't think, but that is what is causing it | 19:24 |
| @avass:vassast.org | yup | 19:24 |
| @clarkb:matrix.org | * that wasn't in your example I don't think, but that is what is what I suspect is causing it | 19:24 |
| @clarkb:matrix.org | ya so your merge failure should remove the vote (which you noted you are not doing). I think if you split the users you could write rules for that though? | 19:25 |
| @clarkb:matrix.org | the pipeline config should allow restricting by user (opendev needs that to accomodate third party CI systems) | 19:25 |
| @avass:vassast.org | A v-2 would still block the change from merging in gerrit, so we'd need to separate the votes :/ | 19:26 |
| @clarkb:matrix.org | Albin Vass: https://opendev.org/openstack/project-config/src/branch/master/zuul.d/pipelines.yaml#L78-L79 is what we do. You would do similar in your gating zuul. And not gate in the other zuul | 19:27 |
| @clarkb:matrix.org | but each of them would restrict the username to their own username when looking for that stuff | 19:27 |
| @clarkb:matrix.org | and our third party CIs do not trigger gating in a loop for broken changing | 19:27 |
| @clarkb:matrix.org | * and our third party CIs do not trigger gating in a loop for broken changes | 19:28 |
| @avass:vassast.org | I guess we could also add a secondary gerrit connection and not add that instance to the gate pipeline | 19:28 |
| @avass:vassast.org | (unless two connection to the same gerrit causes issues for some reason:) | 19:28 |
| @avass:vassast.org | Clark: yeah, that would work if we create another user | 19:29 |
| @clarkb:matrix.org | they are completely separate Zuuls right? I'm not sure why you wold need two connections | 19:29 |
| @clarkb:matrix.org | * they are completely separate Zuuls right? I'm not sure why you wold need two connections in one zuul | 19:29 |
| @clarkb:matrix.org | maybe we should be explicit about this? But I don't think zuul was every designed to share a user with another entity | 19:29 |
| @avass:vassast.org | I mean check would be configured to trigger on events from gerrit, and secondary_gerrit. While gate only would trigger from `gerrit` | 19:29 |
| @clarkb:matrix.org | * maybe we should be explicit about this? But I don't think zuul was ever designed to share a user with another entity | 19:30 |
| @avass:vassast.org | I got a feeling we may have systems that are dependent on the vote coming from that user to do stuff too... :) | 19:30 |
| -@gerrit:opendev.org- Jeremy Stanley https://matrix.to/#/@fungicide:matrix.org proposed: [zuul/zuul-website] 840980: Style heading levels 4-6 https://review.opendev.org/c/zuul/zuul-website/+/840980 | 19:31 | |
| -@gerrit:opendev.org- Jeremy Stanley https://matrix.to/#/@fungicide:matrix.org proposed wip: | 19:31 | |
| - [zuul/zuul-website] 840978: Draft an initial blog article https://review.opendev.org/c/zuul/zuul-website/+/840978 | ||
| - [zuul/zuul-website] 840979: DNM: Add a Lorem Ipsum article https://review.opendev.org/c/zuul/zuul-website/+/840979 | ||
| -@gerrit:opendev.org- Jeremy Stanley https://matrix.to/#/@fungicide:matrix.org proposed on behalf of Clark Boylan: [zuul/zuul-website] 840952: Add a Blog system to the zuul website https://review.opendev.org/c/zuul/zuul-website/+/840952 | 19:31 | |
| @clarkb:matrix.org | er I suppose the actual trigger is a few lines lower: https://opendev.org/openstack/project-config/src/branch/master/zuul.d/pipelines.yaml#L86-L89 | 19:31 |
| @avass:vassast.org | then we'd put migrating repos in the secondary_gerrit connection, so they only trigger check | 19:31 |
| @clarkb:matrix.org | but both the requirement and the trigger do the username filter and we have to do that because multiple CI systems talk to our Gerrit and we only want to Gate if the Gating CI system check sclean | 19:32 |
| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: [zuul/zuul-website] 840982: Add space between blog entries https://review.opendev.org/c/zuul/zuul-website/+/840982 | 19:59 | |
| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: [zuul/zuul-website] 840983: Add space between blog entries https://review.opendev.org/c/zuul/zuul-website/+/840983 | 20:05 | |
| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed wip on behalf of Jeremy Stanley https://matrix.to/#/@fungicide:matrix.org: [zuul/zuul-website] 840979: DNM: Add a Lorem Ipsum article https://review.opendev.org/c/zuul/zuul-website/+/840979 | 20:05 | |
| @jsokolvewd:matrix.org | No idea who I should nag about this, but I was deeply surprised (and forced to update my server running the service) that Zuul/Nodepool 6 dropped support for python 3.6 without any mention of that in release notes... | 20:25 |
| @clarkb:matrix.org | hrm ya it looks like that was missed in the ansible 5 release note (ansible 5 does not support python thta old hence the update | 20:38 |
| -@gerrit:opendev.org- Clark Boylan proposed: [zuul/zuul] 840987: Amend Zuul v6 releaes notes to include python3.8 min version bump https://review.opendev.org/c/zuul/zuul/+/840987 | 20:44 | |
| @clarkb:matrix.org | corvus: fungi ^ I think updating the existing release notes file will put the info in the correct spot but probably worth double checking the build results | 20:46 |
| -@gerrit:opendev.org- Clark Boylan proposed: [zuul/nodepool] 840990: Update releasenotes to capture python3.8 requirement https://review.opendev.org/c/zuul/nodepool/+/840990 | 20:48 | |
| -@gerrit:opendev.org- Clark Boylan proposed: [zuul/nodepool] 840991: Set python metadata in setup.cfg to >=3.8 https://review.opendev.org/c/zuul/nodepool/+/840991 | 20:49 | |
| -@gerrit:opendev.org- Clark Boylan proposed: [zuul/zuul] 840992: Set python-requires to >=3.8 https://review.opendev.org/c/zuul/zuul/+/840992 | 20:50 | |
| @jsokolvewd:matrix.org | Clark: thanks for prompt response :-) | 20:57 |
| @jpew:matrix.org | Can I call a trusted playbook from an untrusted project.... and will it inherit the "trusted-ness" of it? | 20:59 |
| @clarkb:matrix.org | jpew: no you can't call playbooks across projects like that at all iirc. Roles are the unit of sharing | 21:03 |
| @jpew:matrix.org | Clark: So if we have some optional node setup that requires passwords and such, we need to make new jobs in the config project that other jobs can inherit from to get those parts setup? There isn't an easier way for untrusted jobs to opt-in to that sort of thing? | 21:04 |
| @clarkb:matrix.org | jpew: if they are passwords/secretes related to the untrusted repo the untrusted repo could manage them directly for post review tasks. If these are job setup things then you likely need to add this setup to a base job. | 21:07 |
| @clarkb:matrix.org | or at least a parent job in a trusted repo. Not necessary a true bas ejob | 21:07 |
| @jpew:matrix.org | @Clark OK thanks (the secrets in question are passed in via `executor.trusted_ro_path` which I think means we need parent jobs | 21:08 |
| @jpew:matrix.org | * Clark: OK thanks (the secrets in question are passed in via `executor.trusted_ro_path` which I think means we need parent jobs | 21:08 |
| @clarkb:matrix.org | another thing to be careful of is the child jobs accessing that info if it persists across playbooks | 21:09 |
| @jpew:matrix.org | Clark: Like if we use `ansible.builtin.set_fact` with `cachable: true` ? | 21:11 |
| @clarkb:matrix.org | correct | 21:11 |
| @jpew:matrix.org | Or is there another way I'm unaware of | 21:11 |
| @clarkb:matrix.org | you could also explicitly write the data to the workspace filesystem as well I think | 21:11 |
| @clarkb:matrix.org | but caching facts is probably more likely to trip people up | 21:12 |
| @jpew:matrix.org | Sure | 21:12 |
| @clarkb:matrix.org | https://storage.gra.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_c1f/840987/1/check/zuul-tox-docs/c1ffe07/docs/releasenotes.html updating the existing file seems to have done what we want for the release notes | 21:19 |
| @fungicide:matrix.org | jpew: not quite what you were asking, but sometimes used to a similar end... you can pass secrets to playbooks in other projects through a sort of reverse of inheritence: https://zuul-ci.org/docs/zuul/latest/config/job.html#attr-job.secrets.pass-to-parent | 22:33 |
| @fungicide:matrix.org | we use that to run trusted jobs with secrets substituted from consuming projects | 22:34 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!