| ianw | using ... has made it go away. it might be related to firefox 90.0.2, i think i dnf updated recently | 00:10 |
|---|---|---|
| clarkb | fungi: yup they are in my commit message :) | 00:27 |
| fungi | aha, i should find time to read it, clearly | 00:36 |
| *** dmellado_ is now known as dmellado | 00:36 | |
| opendevreview | Ian Wienand proposed zuul/zuul master: web: yarn update to latest @patternfly/react-core https://review.opendev.org/c/zuul/zuul/+/804473 | 05:47 |
| opendevreview | Ian Wienand proposed zuul/zuul master: web: use spread operator in JOB_FETCH_SUCCESS reducer https://review.opendev.org/c/zuul/zuul/+/804474 | 05:47 |
| opendevreview | Ian Wienand proposed zuul/zuul master: web: Job: remove height setting for job page https://review.opendev.org/c/zuul/zuul/+/804475 | 05:47 |
| opendevreview | Ian Wienand proposed zuul/zuul master: web: Job: use PF4 tabs https://review.opendev.org/c/zuul/zuul/+/804476 | 05:47 |
| opendevreview | Ian Wienand proposed zuul/zuul master: web: JobVariant: update to @patternfly/react-icons https://review.opendev.org/c/zuul/zuul/+/804477 | 05:47 |
| opendevreview | Ian Wienand proposed zuul/zuul master: web: JobVariant: use @patternfly/react-table https://review.opendev.org/c/zuul/zuul/+/804478 | 05:47 |
| opendevreview | Ian Wienand proposed zuul/zuul master: web: JobVariant: visual cleanups https://review.opendev.org/c/zuul/zuul/+/804479 | 05:47 |
| opendevreview | Ian Wienand proposed zuul/zuul master: web: Nodeset: convert to a treeview https://review.opendev.org/c/zuul/zuul/+/804480 | 05:47 |
| opendevreview | Ian Wienand proposed zuul/zuul master: web: Add release note for Job/JobVariant changes https://review.opendev.org/c/zuul/zuul/+/804481 | 05:47 |
| opendevreview | Ian Wienand proposed zuul/zuul master: web: use spread operator in JOB_FETCH_SUCCESS reducer https://review.opendev.org/c/zuul/zuul/+/804474 | 05:52 |
| opendevreview | Ian Wienand proposed zuul/zuul master: web: Job: remove height setting for job page https://review.opendev.org/c/zuul/zuul/+/804475 | 05:52 |
| opendevreview | Ian Wienand proposed zuul/zuul master: web: Job: use PF4 tabs https://review.opendev.org/c/zuul/zuul/+/804476 | 05:52 |
| opendevreview | Ian Wienand proposed zuul/zuul master: web: JobVariant: update to @patternfly/react-icons https://review.opendev.org/c/zuul/zuul/+/804477 | 05:52 |
| opendevreview | Ian Wienand proposed zuul/zuul master: web: JobVariant: use @patternfly/react-table https://review.opendev.org/c/zuul/zuul/+/804478 | 05:52 |
| opendevreview | Ian Wienand proposed zuul/zuul master: web: JobVariant: visual cleanups https://review.opendev.org/c/zuul/zuul/+/804479 | 05:52 |
| opendevreview | Ian Wienand proposed zuul/zuul master: web: Nodeset: convert to a treeview https://review.opendev.org/c/zuul/zuul/+/804480 | 05:52 |
| opendevreview | Ian Wienand proposed zuul/zuul master: web: Add release note for Job/JobVariant changes https://review.opendev.org/c/zuul/zuul/+/804481 | 05:52 |
| opendevreview | Felix Edel proposed zuul/zuul master: Fix ordering of parameters in _logQueueStatus() call https://review.opendev.org/c/zuul/zuul/+/804487 | 06:47 |
| *** corvus is now known as Guest4101 | 09:45 | |
| dongzhang[m] | I also have a quick question: There is job config job.success-message in the documentation, and the var (success_message) is also in the Job model class. How ever, this config seems to be no valid any more (from test and source code analysis). Is it somehow leftover that should be removed? | 09:47 |
| *** dviroel|ruck|out is now known as dviroel|ruck | 11:13 | |
| fungi | dongzhang[m]: oh, maybe so, or else that's an unintended regression. we use the pipeline version of those in opendev but not the individual job message attributes | 12:16 |
| dongzhang[m] | If it's some leftover, I would clean it up in source code and documentation. | 12:21 |
| Clark[m] | <tibeer[m]> "Quick question regarding the doc" <- There is a change in progress to make sigterm handling configurable with the default being a graceful stop. | 14:55 |
| clarkb | also tibeer[m]'s original message didn't make it to IRC | 14:55 |
| fungi | ahh, because of the oftc bridge being down at the time | 14:57 |
| opendevreview | James E. Blair proposed zuul/zuul master: Restore job success/failure message https://review.opendev.org/c/zuul/zuul/+/804532 | 14:57 |
| nirmoy | How to get the commit-hash/HEAD from zuul variable which zuul is running on timer trigger pipeline | 14:57 |
| Guest4101 | dong.zhang, fungi: ^ i believe i inadvertently removed success-message, so 804532 restores it. | 14:58 |
| Guest4101 | having said that, i do think we should seriously consider intentionally removing it. it seems like more things are starting to expect at least mostly standard result values. | 14:59 |
| clarkb | Guest4101: note you are not currently corvus (fallout from the bridge issues last night I assume) | 15:01 |
| fungi | nirmoy: you would probably have to get it from the local git checkout, it looks like for timer triggers zuul only has the branch name, not a particular commit id | 15:02 |
| Guest4101 | Clark: thanks | 15:02 |
| *** Guest4101 is now known as notcorvus | 15:03 | |
| *** notcorvus is now known as corvus | 15:03 | |
| *** corvus is now known as reallynotcorvus | 15:04 | |
| nirmoy | fungi: Thanks | 15:04 |
| *** reallynotcorvus is now known as corvus | 15:04 | |
| corvus | clarkb: better? | 15:04 |
| fungi | corvus: yep | 15:04 |
| corvus | clarkb, fungi: thx | 15:05 |
| clarkb | yup | 15:05 |
| clarkb | corvus: on the sqlalchemy change it seems that you do want/need the latest 1.4.22 release from a few weeks ago to get the full compatiblity stuff. Should I set a sqlalchemy>=1.4.22 on that change? | 16:02 |
| clarkb | looking at https://review.opendev.org/c/zuul/zuul/+/804474/2/web/src/reducers/job.js does line 33 change the return type/value of that function? | 16:12 |
| clarkb | or is that first ..state like a for each state make a dict entry? | 16:14 |
| clarkb | if I read the docs properly it should add isFetching: false, jobs: {} to the dict then we immediately override those values? | 16:16 |
| clarkb | I left a comment on ^ if someone that groks js better than me wants to check it | 16:19 |
| clarkb | ianw: I did my best to review the job and nodeset UI changes. Overall I think they look good with my biggest concern being the lack of the vertical separator on those job variant tabs | 17:05 |
| clarkb | left comments on some other stuff too | 17:05 |
| pabelanger[m] | Am I right in thinking, that a pipeline cannot be configured to dequeue a change, based on a label event? Or, would I use https://zuul-ci.org/docs/zuul/reference/pipeline_def.html#attr-pipeline.dequeue and setup the unlabel trigger? | 18:07 |
| pabelanger[m] | from my reading, it is only a reporter so I don't believe I can attach an unlabeled trigger | 18:08 |
| pabelanger[m] | we have a use case, where if a user applies the gate label, zuul enqueues the change. However, if they want to stop the merge, removing 'gate' label has no affect | 18:09 |
| clarkb | I think that is correct. Same issue if you unapprove a change in gerrit it isn't dequeued | 18:09 |
| pabelanger[m] | right | 18:09 |
| clarkb | in the gerrit case it cannot merge when you do that so hasn't been a big deal for us | 18:09 |
| clarkb | I guess it can still merge in the github case? | 18:09 |
| pabelanger[m] | yah, because we depend on branch protection conditions in github api | 18:10 |
| pabelanger[m] | let me check something | 18:10 |
| pabelanger[m] | when I last looked at this, I thought having 'gate' as a pipeline.requirement was enough however that check only happens when the change enters the pipeline | 18:11 |
| pabelanger[m] | we have an 'unlabel-on-push' pipeline, that removes gate when new PRs are uploaded. I am thinking I need to do the same for when gate is removed. But even then, I don't know of a way to cancel the running jobs today | 18:14 |
| pabelanger[m] | I remember reading about github api to abort a job | 18:14 |
| pabelanger[m] | https://zuul-ci.org/docs/zuul/reference/releasenotes.html#relnotes-4-0-0-new-features | 18:15 |
| pabelanger[m] | maybe that is just the way to go right now | 18:15 |
| clarkb | looking in the dependent pipeline we only check canMerge at enqueue time and don't check again after testing is done | 18:16 |
| clarkb | in the gerrit case gerrit itself prevents merging when the +A isn't there anymore | 18:16 |
| clarkb | zuul can probably do those checks internally before it attemping to merge too then you justh ave to ensure the canMerge check in the driver is correct? | 18:17 |
| pabelanger[m] | maybe | 18:17 |
| pabelanger[m] | so far it hasn't been a big issue, but it has come up from time to time | 18:18 |
| clarkb | also when the gerrit driver gets a new patchset event it dequeues the old patchset in zuul | 18:18 |
| clarkb | not sure why you couldn't do similar in the github driver | 18:18 |
| pabelanger[m] | yah, that's what we do too | 18:18 |
| pabelanger[m] | as a quick way, push up new change to dequeue everything | 18:18 |
| clarkb | you said you use a separate pipeline for that though | 18:19 |
| pabelanger[m] | yah | 18:19 |
| fungi | i would say, if zuul were to start checking merge conditions more often, then maybe it should check them more frequently (every queue update?) so as to dequeue sooner | 18:19 |
| clarkb | with gerrit it is built into the driver | 18:19 |
| fungi | rather than just at the end | 18:19 |
| clarkb | fungi: that could get expensive. I think you could check the mergeability of a change whenever you get an event for that change though? | 18:19 |
| fungi | though i suppose that implies more api calls | 18:19 |
| fungi | yeah, maybe any time we would otherwise already be querying that | 18:20 |
| fungi | so as not to increase the query frequency needlessly | 18:20 |
| fungi | which might wind up being only at enqueue and at the end, but could be sooner | 18:20 |
| clarkb | there are probably reasons why the github driver doesn't do the dequeue on PR update that I don't know about, but seems like for parity with gerrit that would be a nice thing to have | 18:20 |
| pabelanger[m] | for github, if you edit the commit message it will dequeue (but not reenqueue) same goes for new PR. So, I'm missing which part of gerrit that isn't the same | 18:23 |
| pabelanger[m] | (commit message == first comment) | 18:23 |
| clarkb | pabelanger[m]: with gerrit we don't need a separate pipeline to make that change. It is built into the driver. Maybe I'm not undersatnding what you mean by separate pipeline | 18:24 |
| clarkb | "we have an 'unlabel-on-push' pipeline, that removes gate when new PRs are uploaded." is the bit I'm talking about | 18:25 |
| clarkb | oh maybe that is only for removing the label | 18:25 |
| clarkb | and the dequeue is built in just like with gerrit, that would explain my confusion | 18:26 |
| pabelanger[m] | clarkb: ah, the 2nd pipeline is unlabel 'gate' when we push a new PR. Because, I have no idea how to only do that on a single event in check: https://github.com/ansible/project-config/blob/master/zuul.d/pipelines.yaml#L232 | 18:28 |
| pabelanger[m] | this is to avoid new PRs being able to go directly into gate without a human applying the label | 18:28 |
| clarkb | gotcha | 18:28 |
| pabelanger[m] | I wonder if I can do that on dequeue reporter now | 18:28 |
| pabelanger[m] | no, because I still only want to unlabel for 'changed' action on single event | 18:29 |
| clarkb | fungi: I updated the openstack-discuss thread on sqlalchemy 2.0 with the bits we learned about python warnings | 18:36 |
| fungi | i saw (and read)! thanks | 18:41 |
| pabelanger[m] | so we are all in on the builset-registry for container builds, in fact we've just now flipping our integration testing to be all driven via containers. I think the last missing feature we need (and pretty sure I discussed before) is the ability to unpause a paused job. Once we get all our artifacts from our buildset registry, we could release that node back to nodepool. | 19:01 |
| pabelanger[m] | Right now, it could be upwards of 3 hours it is paused for depending on integration tests | 19:01 |
| fungi | that does sound like a reasonable feature, i guess the dependent jobs would just need a way of communicating they're done with the paused build, and then once all of them checked in that way zuul would unpause it? | 19:04 |
| fungi | is that complicated by transitive dependencies? | 19:05 |
| fungi | (depends on a job which depends on a paused job?) | 19:05 |
| pabelanger[m] | Yah, I imagine we'd use zuul_return: unpause as the method | 19:06 |
| pabelanger[m] | zuul already tracks the child_jobs for paused today, and unpauses properly so we should be able to continue to use that | 19:06 |
| pabelanger[m] | let me poke into how it all works again | 19:07 |
| pabelanger[m] | lulz, this won't be a 5min process. Guess I'll have to write a test cases first, then add the code | 19:15 |
| pabelanger[m] | however, that won't be for today | 19:16 |
| fungi | i highly recommend test-driven development, but especially with zuul's scheduler behaviors | 19:17 |
| fungi | so test case first and then adjust the code until it works sounds ideal | 19:18 |
| *** dviroel|ruck is now known as dviroel|out | 19:42 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!