@chgans:matrix.org | Hi, that sounds interesting, could you elaborate a bit? We're considering switching to Zuul, and we do embedded SW too, which is tested on device farms. | 03:33 |
---|---|---|
@iwienand:matrix.org | as discussed in the opendev meeting today, i've filed https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1015740 about the glibc hang issue | 04:04 |
@iwienand:matrix.org | i honestly don't have high hopes it will attract the interest of those who could do anything about it, but you never know | 04:05 |
-@gerrit:opendev.org- Matthieu Huin https://matrix.to/#/@mhuin:matrix.org proposed: [zuul/zuul] 848093: zuul-web: raise 404s when tenant isn't found https://review.opendev.org/c/zuul/zuul/+/848093 | 09:21 | |
-@gerrit:opendev.org- Matthieu Huin https://matrix.to/#/@mhuin:matrix.org proposed: [zuul/zuul] 848132: zuul-web: return errors as JSON https://review.opendev.org/c/zuul/zuul/+/848132 | 09:53 | |
-@gerrit:opendev.org- Matthieu Huin https://matrix.to/#/@mhuin:matrix.org proposed: [zuul/zuul] 850369: [WIP] UI: Improve API error handling https://review.opendev.org/c/zuul/zuul/+/850369 | 09:53 | |
-@gerrit:opendev.org- Matthieu Huin https://matrix.to/#/@mhuin:matrix.org proposed: [zuul/zuul] 850369: [WIP] UI: Improve API error handling https://review.opendev.org/c/zuul/zuul/+/850369 | 10:13 | |
-@gerrit:opendev.org- Benjamin Schanzel proposed on behalf of Tobias Henkel: [zuul/zuul] 756077: Increase merge retries and delays in between https://review.opendev.org/c/zuul/zuul/+/756077 | 11:22 | |
-@gerrit:opendev.org- Benjamin Schanzel proposed on behalf of Tobias Henkel: [zuul/zuul] 756077: Increase merge retries and delays in between https://review.opendev.org/c/zuul/zuul/+/756077 | 11:44 | |
@erbarr:matrix.org | hello, so I have a config project where I defined jobs and pipelines that get run on changes to an upstream project where I can't define said jobs and pipelines. I now need to have a way to change what jobs get run based on what branch caused the trigger. How can I do that? | 15:35 |
@clarkb:matrix.org | erbarr: the intended simple way for that is to define which jobs get run in the branches creating the triggers. Then whatever jobs are listed by the branch will be triggered. Since you cannot do that what you can do is annotate the jobs in the pipeline or job definition config with branch specifiers indicating which branches they should run against. I would do this in a config project that is not branched itself (so that you don't end up with multiple definitions of that config specifying different branches) | 15:38 |
@erbarr:matrix.org | annotate? | 15:40 |
@clarkb:matrix.org | Annotate is probably the wrong word. Add a branch specifier to the job | 15:41 |
@erbarr:matrix.org | can i do that at the pipeline level? I really need to run different sets of jobs for different branches as some things are not available in older branches | 15:43 |
@clarkb:matrix.org | erbarr: https://opendev.org/openstack/project-config/src/branch/master/zuul.d/projects.yaml#L6886-L6894 is an example | 15:45 |
@clarkb:matrix.org | that says when the master branch triggers jobs run the noop job. When a stable branch triggers the job run the legacy-tempest-dsvm-lxd-ovs job. | 15:45 |
@clarkb:matrix.org | You can do the same thing in the job config (really what that pipeline config does is create a pipeline specific job variant at that point) | 15:46 |
@erbarr:matrix.org | ahh, nice, thanks! that's what I need | 15:46 |
@clarkb:matrix.org | erbarr: just avoid adding that config to a project that will be branched later because then you'll end up with two copies of that config that zuul has to reconcile and it can be confusing | 15:47 |
@clarkb:matrix.org | the openstack/project-config repo has a single branch (master) and won't grow any new ones in my example | 15:47 |
@erbarr:matrix.org | okay thanks, that's the plan. So, just to make sure, i'd need a regex to match stables that are supported and master only and that job will be skipped if the trigger doesnt match the regex, right? | 15:50 |
@clarkb:matrix.org | > <@jpew:matrix.org> w.r.t ^^, this is really useful for us because we are building embedded targets, then testing them on a hardware cluster (where hardware resources are limited). This allows us to prioritize the things at the head of the gate queue to allocated a hardware resource for testing over the things further down in the queue | 15:51 |
Is this something you could currently do using a normal job var? It doesn't seem like this is something that zuul is taking action on directly, but instead the ansible job environment must do somethign with it? In that case it should be sufficient to use a job var? | ||
@jpew:matrix.org | > <@clarkb:matrix.org> Is this something you could currently do using a normal job var? It doesn't seem like this is something that zuul is taking action on directly, but instead the ansible job environment must do somethign with it? In that case it should be sufficient to use a job var? | 16:01 |
Clark: Zuul knows the relative priority (position) of things in the gate queue; unless there is another way I'm unaware of to get that? (or I'm misunderstanding what you are saying) | ||
@clarkb:matrix.org | jpew: I think I read it first as a static value you wanted to set. But now I see you are trying to send the dynamic value into the zuul vars for the job? I Guess that makes sense | 16:03 |
@jpew:matrix.org | Clark: I'm open to another way to do it there are ideas.... I'm having a little trouble getting it to work in the test case I wrote (all the jobs have a priority of 0) | 16:04 |
@clarkb:matrix.org | it also looks like some existing test cases don't like getNodePriority being called in some cases | 16:05 |
@jpew:matrix.org | Ya, there are few corner cases when it's called from the Web UI in particular (something about a "job freezing" path? Not sure) | 16:06 |
@clarkb:matrix.org | re always being 0 it is based on item position in the pipeline which means all jobs for the first item will have a priority 0. Then the second item enqueued should have a priority of 1 | 16:07 |
@clarkb:matrix.org | Are you enqueuing more than one item? | 16:07 |
@jpew:matrix.org | I think so.... here is my test: | 16:22 |
``` | ||
def test_node_priority(self): | ||
"Test node priority" | ||
self.executor_server.hold_jobs_in_build = True | ||
A = self.fake_gerrit.addFakeChange('org/project', 'master', 'A') | ||
B = self.fake_gerrit.addFakeChange('org/project', 'master', 'B') | ||
C = self.fake_gerrit.addFakeChange('org/project', 'master', 'C') | ||
A.addApproval('Code-Review', 2) | ||
B.addApproval('Code-Review', 2) | ||
C.addApproval('Code-Review', 2) | ||
self.fake_gerrit.addEvent(A.addApproval('Approved', 1)) | ||
self.fake_gerrit.addEvent(B.addApproval('Approved', 1)) | ||
self.fake_gerrit.addEvent(C.addApproval('Approved', 1)) | ||
self.waitUntilSettled() | ||
self.executor_server.release() | ||
self.waitUntilSettled() | ||
self.assertEqual(len(self.builds), 3) | ||
for idx, build in enumerate(self.builds): | ||
print(idx, build) | ||
self.assertEqual(build.parameters['zuul']['node_priority'], idx) | ||
self.executor_server.hold_jobs_in_build = False | ||
self.executor_server.release() | ||
self.waitUntilSettled() | ||
``` | ||
@clarkb:matrix.org | That looks about right. I'm not sure why they would all report 0 just reading the code here | 16:26 |
@jpew:matrix.org | Ok, I'll keep digging | 16:26 |
@jim:acmegating.com | jpew: make sure relative priority is enabled for the test | 16:37 |
@jpew:matrix.org | corvus: I'll try that, but I don't _think_ it matters because it looks like that is only checked at the time that the nodepool request is created and not generally when getNodePriority() is called | 16:41 |
@jim:acmegating.com | ack, that may be. was just an off the cuff idea of something to check. :) | 16:46 |
@jpew:matrix.org | I think the code acutally works, but I'm grossly misunderstanding how to check for it in the test case :) | 18:39 |
-@gerrit:opendev.org- Tristan Cacqueray proposed: [zuul/zuul] 850575: doc: fix liveness probes path rendering https://review.opendev.org/c/zuul/zuul/+/850575 | 18:57 | |
-@gerrit:opendev.org- Tristan Cacqueray proposed: [zuul/zuul-operator] 850576: Add prometheus readiness probe https://review.opendev.org/c/zuul/zuul-operator/+/850576 | 19:01 | |
-@gerrit:opendev.org- Joshua Watt proposed: | 21:21 | |
- [zuul/zuul] 850351: Add node_priority job variable https://review.opendev.org/c/zuul/zuul/+/850351 | ||
- [zuul/zuul] 850584: model: Pipeline: Return empty list of queues if no state https://review.opendev.org/c/zuul/zuul/+/850584 | ||
- [zuul/zuul] 850585: manager: Handle queue item not existing in the queue https://review.opendev.org/c/zuul/zuul/+/850585 | ||
@jpew:matrix.org | It was just a problem in the test I wrote :) | 21:21 |
@jpew:matrix.org | works now | 21:21 |
@jpew:matrix.org | Although... perhaps it should be just `priority` instead of `node_priority` since it's not the actual priority of the node allocation (due to the relative priority flag?) | 21:22 |
@clarkb:matrix.org | jpew: zuul does internally refer to it as node priority. I think that name is probably fine | 21:23 |
@clarkb:matrix.org | jpew: left a suggestion on 850585 | 21:41 |
@jim:acmegating.com | Clark: jpew -- i see a couple of changes that look like they're fixes for exceptions but they don't have tests -- if we're fixing bugs like that can we include tests please? | 21:49 |
@jpew:matrix.org | The test for 850585 would effectively be calling getNodePriority(), which is what 850351 does; is a more explict test needed? | 21:52 |
@jim:acmegating.com | if it's a fix covered by a later test, it would be good to mention that in the commit message so we know the changes are tied together. we'll know not to merge the changes ahead until the change with the test is approved | 21:54 |
@jpew:matrix.org | Ah, more so that using the same topic? | 21:54 |
@clarkb:matrix.org | I think those changes can be squashed together | 21:55 |
@clarkb:matrix.org | The test added covers it | 21:55 |
@jim:acmegating.com | absolutely -- i would be happy to merge a bugfix change immediately with a test, but not without it | 21:55 |
@jim:acmegating.com | yes, squashing is fine too | 21:55 |
@jpew:matrix.org | Ya, the fixes are all from the new code path of calling getNodePriority() in 850351 | 21:55 |
@jpew:matrix.org | I'll squash them | 21:56 |
@jim:acmegating.com | (topics have no impact to how changes in opendev are merged; they can be merged one at a time or in series. to be explicit: opendev's gerrit does not have submitWholeTopic enabled, so every change stands alone) | 21:56 |
@jpew:matrix.org | corvus: Right, I guess I meant the combination of stacked changes in a topic. either way squashing is fine :) | 21:57 |
@jim:acmegating.com | yeah, the only signal we're going to take from a series of stacked changes is the end of the stack depends on the beginning; we often merge the top of a stack before the bottom. but i don't want to merge bugfixes without tests, so in that case we either need to include the test with the fixes, or have some indication that the whole stack should be merged together. either is fine. | 21:58 |
-@gerrit:opendev.org- Ian Wienand proposed: [zuul/zuul] 850269: [wip] zuul-stream: start new console for stream tests https://review.opendev.org/c/zuul/zuul/+/850269 | 22:27 | |
-@gerrit:opendev.org- Ian Wienand proposed: [zuul/zuul] 850269: [wip] zuul-stream: start new console for stream tests https://review.opendev.org/c/zuul/zuul/+/850269 | 23:13 | |
-@gerrit:opendev.org- Ian Wienand proposed: [zuul/zuul] 850269: [wip] zuul-stream: start new console for stream tests https://review.opendev.org/c/zuul/zuul/+/850269 | 23:28 | |
-@gerrit:opendev.org- Ian Wienand proposed: [zuul/zuul] 850269: [wip] zuul-stream: start new console for stream tests https://review.opendev.org/c/zuul/zuul/+/850269 | 23:38 | |
@iwienand:matrix.org | i think the reason i see a broken image on all these gerrit messages is something like https://github.com/matrix-org/synapse/issues/13016 ... it's trying to make a dynamic screenshot of the page or something? | 23:44 |
@iwienand:matrix.org | interesting ... i see the screenshot above. but not on the gerrit messages | 23:45 |
@clarkb:matrix.org | There is a preview card protocol that I think Twitter defined that websites have to support for that to work | 23:47 |
@clarkb:matrix.org | I looked at it briefly for Gerrit but it's weird because you need to do JavaScript to load the data and those requests never run any js. | 23:47 |
@iwienand:matrix.org | oh interesting! | 23:50 |
@clarkb:matrix.org | Gerrit needs us to run to load the data I should say | 23:51 |
@clarkb:matrix.org | * Gerrit needs js to run to load the data I should say | 23:51 |
@iwienand:matrix.org | if it's https://developer.twitter.com/en/docs/twitter-for-websites/cards/overview/summary it looks like just meta tags | 23:53 |
@iwienand:matrix.org | i guess it could serve a generic image | 23:53 |
@iwienand:matrix.org | oh i see what you're saying; it's a big react app that doesn't just serve html | 23:54 |
@iwienand:matrix.org | not react, whatever the heck it is | 23:55 |
@clarkb:matrix.org | Ya it's just tags in html but to do anything useful you need data. I think you'd need to update Gerrit to send that info along with the json blob that can load all the rest of it | 23:55 |
@clarkb:matrix.org | Polygerrit based on polysomethint | 23:55 |
@clarkb:matrix.org | * Ya it's just tags in html but to do anything useful you need data. I think you'd need to update Gerrit to send that info along with the js blob that can load all the rest of it | 23:55 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!