*** wuchunyang has joined #zuul | 00:15 | |
*** wuchunyang has quit IRC | 00:19 | |
*** ikhan has joined #zuul | 00:20 | |
*** iurygregory has quit IRC | 01:26 | |
*** zenkuro has quit IRC | 02:01 | |
*** zenkuro has joined #zuul | 02:02 | |
*** ikhan has quit IRC | 02:28 | |
*** Goneri has quit IRC | 02:31 | |
*** zenkuro has quit IRC | 02:43 | |
*** zenkuro has joined #zuul | 02:43 | |
*** bhavikdbavishi has joined #zuul | 03:08 | |
*** bhavikdbavishi has quit IRC | 03:59 | |
*** bhavikdbavishi1 has joined #zuul | 03:59 | |
*** bhavikdbavishi1 has quit IRC | 04:00 | |
*** bhavikdbavishi has joined #zuul | 04:00 | |
*** wuchunyang has joined #zuul | 04:02 | |
*** wuchunyang has quit IRC | 04:07 | |
*** zenkuro has quit IRC | 05:07 | |
*** vishalmanchanda has joined #zuul | 05:32 | |
*** evrardjp has quit IRC | 05:33 | |
*** evrardjp has joined #zuul | 05:33 | |
*** wuchunyang has joined #zuul | 05:45 | |
*** zenkuro has joined #zuul | 06:10 | |
*** bhavikdbavishi has quit IRC | 06:18 | |
*** bhavikdbavishi has joined #zuul | 06:20 | |
*** bhavikdbavishi has quit IRC | 06:45 | |
*** rpittau|afk is now known as rpittau | 06:47 | |
ianw | felixedel: we should skip tasks that fail but are failed_when: false like in https://zuul.opendev.org/t/pypa/build/248c7f4eef274cf5ac7fc8c15f42a598 (https://opendev.org/zuul/zuul-jobs/src/branch/master/roles/ensure-tox/tasks/main.yaml#L7) | 07:08 |
---|---|---|
felixedel | ianw: What do you mean? | 07:16 |
ianw | felixedel: if you look at the task summary page, it shows that task as failed, when it was supposed to fail but we ignore it | 07:17 |
ianw | it's a bit confusing | 07:17 |
ianw | there's two there, checking if tox and pip are installed | 07:17 |
felixedel | Ah, task summary. Yes that would be an improvement | 07:18 |
felixedel | So in case of the pypa-pip-py38 the build failed, but only due to one task and not to all three, right? | 07:19 |
*** bhavikdbavishi has joined #zuul | 07:20 | |
ianw | that's right, just the last one (the tox failure) | 07:20 |
felixedel | ok. Btw, I like the new design with the red cross and the bold task and host names. IMHO much better readable than the previous version ;-) | 07:22 |
tobiash | ianw: I've responded on https://review.opendev.org/756325 (dib in venv) | 07:24 |
*** zenkuro has quit IRC | 07:35 | |
*** zenkuro has joined #zuul | 07:35 | |
*** jcapitao has joined #zuul | 07:42 | |
openstackgerrit | Felix Edel proposed zuul/zuul master: UI: Remove stretchable link from build and buildset table https://review.opendev.org/761621 | 07:57 |
openstackgerrit | Felix Edel proposed zuul/zuul master: UI: Remove stretchable link from build and buildset table https://review.opendev.org/761621 | 07:59 |
*** iurygregory_ has joined #zuul | 08:09 | |
*** iurygregory_ is now known as iurygregory | 08:14 | |
openstackgerrit | Daniel Pawlik proposed zuul/zuul master: Improve Elasticsearch reporter doc and driver, changed index name https://review.opendev.org/761441 | 08:19 |
*** jcapitao has quit IRC | 08:53 | |
*** jcapitao has joined #zuul | 08:55 | |
*** bhavikdbavishi has quit IRC | 08:56 | |
*** jpena|off is now known as jpena | 08:57 | |
*** bhavikdbavishi has joined #zuul | 09:01 | |
*** jcapitao is now known as jcapitao_afk | 09:02 | |
*** jcapitao_afk is now known as jcapitao | 09:39 | |
*** jcapitao has quit IRC | 09:44 | |
*** jcapitao has joined #zuul | 09:46 | |
openstackgerrit | Daniel Pawlik proposed zuul/zuul master: Improve Elasticsearch reporter doc and driver, changed index name https://review.opendev.org/761441 | 09:48 |
*** bhavikdbavishi has quit IRC | 09:51 | |
*** wuchunyang has quit IRC | 10:25 | |
*** wuchunyang has joined #zuul | 10:26 | |
*** wuchunyang has quit IRC | 10:32 | |
*** jfoufas1 has joined #zuul | 10:33 | |
zbr | tobiash: felixedel: https://review.opendev.org/#/c/761293/ please, very simple. | 10:44 |
*** bhavikdbavishi has joined #zuul | 10:49 | |
*** hashar has joined #zuul | 10:54 | |
*** wuchunyang has joined #zuul | 11:09 | |
*** bhavikdbavishi has quit IRC | 11:16 | |
avass | tristanC: can you take a look at zbr's change ^ ? | 11:49 |
*** jcapitao is now known as jcapitao_lunch | 11:49 | |
zbr | 0755/0644 are not default, is likely implicit but not default. there is no documented default for any "mode" in ansible modules | 11:51 |
zbr | in fact that was one of the reasons why E208 was created | 11:51 |
zbr | avass: there are still open (unresolved) bugs on ansible related to the file modes, and i got confirmation from bcoca few days ago that explicit is recomanded. | 11:54 |
zbr | in fact it is recommended inside the source code of ansible to be explicit | 11:54 |
*** wuchunyang has quit IRC | 12:00 | |
*** rfolco has joined #zuul | 12:06 | |
*** bhavikdbavishi has joined #zuul | 12:19 | |
*** jpena is now known as jpena|lunch | 12:36 | |
openstackgerrit | Simon Westphahl proposed zuul/zuul master: Implementation of Zookeeper backed event queues https://review.opendev.org/761170 | 12:39 |
openstackgerrit | Simon Westphahl proposed zuul/zuul master: Implementation of Zookeeper event watcher https://review.opendev.org/761171 | 12:39 |
openstackgerrit | Simon Westphahl proposed zuul/zuul master: Switch to Zookeeper backed trigger event queues https://review.opendev.org/761172 | 12:39 |
openstackgerrit | Simon Westphahl proposed zuul/zuul master: wip: Switch to Zookeeper backed management event queues https://review.opendev.org/761738 | 12:39 |
tristanC | zbr: if they are not the default values, when are they not used? In other words, how ansible decide which values to use? | 12:47 |
zbr | tristanC: sorry to say, but I found your questions bit... draining. Whatever explanation I gave you already found another question to ask. | 12:54 |
zbr | when i posted link to https://github.com/ansible/ansible/issues/67794 i did not get any reply | 12:54 |
zbr | that is from yesterday from #ansible-deve channel: https://sbarnea.com/ss/Screen-Shot-2020-11-06-12-55-11.49.png | 12:57 |
*** jcapitao_lunch is now known as jcapitao | 12:59 | |
zbr | and to repeat for the n-time: defaults are not documeted in ansible and they are like this for a good reason: they do not yet know what to say about them and they are subject to change, as they were already changed several times during this year. | 13:00 |
*** tosky has joined #zuul | 13:07 | |
tristanC | zbr: if i understand the issue 67794 correctly, the default mode value is world readable unless a non default umask is set on the target system? | 13:19 |
tristanC | zbr: i'm sorry to keep on asking, but i'm not familiar with ansible internal and that bug report is hard to read. I am looking for a more simple reason to respect the 208 rule, which i find quite intrusive considering the amount of task that relies on ansible default behavior | 13:23 |
*** bhavikdbavishi has quit IRC | 13:27 | |
*** jpena|lunch is now known as jpena | 13:32 | |
zbr | tristanC: attempt to resume it: in order to avoid potentially security issues is better to be explicit on file mode everywhere. this forces the playbook writer to think twice. | 13:48 |
zbr | yep, likely the number of places where non default permissions are needed is <10%, based on zuul-jobs repo which had >100 occurences. | 13:49 |
zbr | it is impossible for the linter to guess where security matters or not, so the approach is to be always explicit. | 13:50 |
zbr | most of the time is 0755/0644, but as we seen with current patches we keep discovering tricky areas where it should not be. | 13:51 |
fungi | but is it the job of a syntax linter to warn you about possible security blind spots? | 13:51 |
zbr | fungi: do you think that using lowercase L letter as variable name is good practice? | 13:51 |
zbr | more recent versions of flake8 made it an error too, it fits the same use-case. While the code may not be broken as it is, it may become broken in the future. | 13:53 |
zbr | there is wide range of categories of issues that are spotted, some are style, readability, deprecations, security, idempotence,... in the end a human needs to decide what to act on or not. | 13:54 |
zbr | IMHO, even if we have a single case of too relaxed permissions it would count as a good enough case to use it. | 13:55 |
zbr | as an anecdote, I do remember few years back there were people arguing that adding "name" to all ansible tasks tasks made no sense, as they were self-explanatory. | 13:57 |
zbr | lucky, i do not see these kind of comments anymore. | 13:57 |
fungi | it just seems like the main concern with 208 is that, since the linter can't know what the "correct" permissions are for a file, sure it's possible you forgot to set strict permissions on something but it's just as possible that you explicitly set incorrect permissions (i saw that in puppet all the time when people would cut and paste another resource and change a few details) | 13:59 |
fungi | forcing someone to set permissions doesn't necessarily increase the chances that they choose the correct permissions | 14:00 |
zbr | if unsure you can always add a "# noqa: 208" comment to silence it. | 14:01 |
avass | tosky: you don't happen to have a way around windows double-hop security thingy with certificate authentication? | 14:07 |
avass | tobiash: whoops ^ | 14:08 |
tosky | np :) | 14:08 |
avass | tobiash: the fix to use multiple disk letters in 740110 works on our cloud nodes where we don't need it but not on our on-prem ones where we actually need it since it's not allowed to check UNC paths (//localhost/c$/...). | 14:11 |
tobiash | avass: what do you mean with double-hop? | 14:11 |
fungi | zbr: originally i thought the point of 208 was to ease the upcoming default transition. there was that regression where ansible tried to resolve a (key permissions related?) issue by making file resources no longer rely on umask and instead always default to o0600 which broke horribly for lots of folks, so they resolved to only do that in a later release instead but would need to get everyone to start being | 14:12 |
fungi | more explicit about their permissions instead of relying on the default to allow the default to be changed gracefully? | 14:12 |
zbr | fungi: true. still, be aware that it is likely to see future changes from ansible in that area. | 14:14 |
zbr | they made several changes but the subject it not closed | 14:14 |
avass | tobiash: I believe it's this: https://docs.microsoft.com/en-us/powershell/scripting/learn/remoting/ps-remoting-second-hop?view=powershell-7 | 14:15 |
fungi | right, that's what i'm saying, if the point of 208 is to make sure that our file resources are forward-compatible with future ansible release plans to change the default mode, then that seems like a better reason to rely on it. the "but security!" argument is fairly hollow | 14:15 |
avass | i wouldn't expect //localhost/ to check anything than the local machine but seems like it does (when it's connected to an AD network?) | 14:15 |
tobiash | avass: I've never tried winrm multi hop | 14:19 |
avass | me netiher, I guess it would just work if we didn't allow multiple drive letters | 14:20 |
openstackgerrit | Felix Edel proposed zuul/zuul master: UI: Disable links on skipped builds in build table https://review.opendev.org/761749 | 14:23 |
*** hashar has quit IRC | 14:23 | |
*** jfoufas1 has quit IRC | 14:27 | |
openstackgerrit | Simon Westphahl proposed zuul/zuul master: Switch to Zookeeper backed trigger event queues https://review.opendev.org/761172 | 14:45 |
openstackgerrit | Simon Westphahl proposed zuul/zuul master: wip: Switch to Zookeeper backed management event queues https://review.opendev.org/761738 | 14:45 |
*** Goneri has joined #zuul | 14:46 | |
pabelanger | morning, so we in zuul.a.c are dealing with the issue of invalid tags in git repos. Basically, people don't understand that deleting a git tag is bad, which is leading to missing sha1 in our zuul-mergers, and jobs fail to start because of it. I know we put in a fix for dangling head in git, could we do something to refresh git tags on failure? | 14:47 |
pabelanger | it leads to a lot of manualy work to search all git cache for the deleted tag, to manually delete it | 14:47 |
swest | pabelanger: there is a --prune-tags option for git, but IIRC that's only available in git >= 2.17.0 | 14:51 |
pabelanger | git fetch --prune origin "+refs/tags/*:refs/tags/*" | 14:54 |
pabelanger | is what I see | 14:54 |
pabelanger | which did work locally | 14:54 |
pabelanger | I wonder if we could do that periodically, or when we raise an exception | 14:55 |
swest | git fetch --prune --prune-tags origin | 14:55 |
pabelanger | http://paste.openstack.org/show/799788/ | 14:56 |
pabelanger | is what we see | 14:56 |
avass | pabelanger: I thought there already was a fix for that since we had the same problems like half a year ago | 14:57 |
avass | maybe our users actually listened | 14:57 |
avass | yeah maybe I'm just misremembering | 14:58 |
pabelanger | avass: it could be fixed, we are running 3.19.1 | 14:58 |
avass | so are we :) | 14:58 |
openstackgerrit | Simon Westphahl proposed zuul/zuul master: wip: Prune also tags on fetch https://review.opendev.org/761756 | 15:02 |
swest | pabelanger: ^ something like that might work | 15:02 |
pabelanger | swest: thanks, I was just looking at that code | 15:03 |
*** vishalmanchanda has quit IRC | 15:12 | |
avass | tobiash: looks like you can get around it by installing a loopback adapter :^) | 15:15 |
*** rpittau is now known as rpittau|afk | 15:18 | |
*** is_null has joined #zuul | 15:18 | |
*** bhavikdbavishi has joined #zuul | 16:00 | |
*** sshnaidm_ has joined #zuul | 16:12 | |
*** sshnaidm|afk has quit IRC | 16:13 | |
*** bhavikdbavishi has quit IRC | 16:15 | |
*** bhavikdbavishi has joined #zuul | 16:19 | |
*** sshnaidm_ is now known as sshnaidm|afk | 16:21 | |
*** bhavikdbavishi has quit IRC | 16:23 | |
openstackgerrit | Merged zuul/zuul-jobs master: More E208 https://review.opendev.org/761293 | 16:25 |
*** jcapitao has quit IRC | 17:33 | |
corvus | tristanC: want to +w https://review.opendev.org/728118 ? | 17:38 |
corvus | (i think your comments are addressed) | 17:38 |
corvus | tobiash: ditto on https://review.opendev.org/751312 | 17:40 |
corvus | tobiash: and https://review.opendev.org/750709 | 17:44 |
*** jpena is now known as jpena|off | 18:02 | |
openstackgerrit | Merged zuul/zuul-website master: Add link to zuul-client documentation https://review.opendev.org/751312 | 18:03 |
corvus | mhu: i'm digging up the dockerhub secret and will update your change with it | 18:04 |
mhu | corvus, nice thanks! Otherwise I'm fine with just having containers generated in the CI. Users can get zuul-client from pip and it's now packaged in Fedora 34. | 18:06 |
mhu | but I won't mind another way to use the CLI | 18:06 |
corvus | mhu: it's easy, and yeah, i could see "docker run" being a convenient way for folks to do it | 18:06 |
mhu | plus I have to hand it to the opendev folks, it was super easy to create that docker image | 18:07 |
fungi | awesome to hear | 18:08 |
openstackgerrit | James E. Blair proposed zuul/zuul-client master: Add Dockerfile https://review.opendev.org/755519 | 18:11 |
corvus | mhu: ^ | 18:11 |
mhu | corvus, thanks! LGTM if you're okay with it | 18:12 |
corvus | heh i love we're building arm images of it too :) | 18:13 |
corvus | mhu: though, that could slow things down. do you think it's important? | 18:14 |
mhu | the arm images? I didn't even know about them :) | 18:15 |
corvus | (i think we only do that for nodepool builders now, and that's so they can build arm images). i guess we're asking whether we think we have many users using arm workstations... | 18:15 |
corvus | mhu: i'll leave a comment | 18:15 |
clarkb | in particular the package installation steps that run compiles are very slow in the emulated arm build env | 18:16 |
mhu | right, I guess I iterated from an existing image build job and didn't notice the arm arch in the vars | 18:17 |
mhu | I'm sure the people on arm workstations won't complain if we don't build an image for them | 18:18 |
openstackgerrit | Merged zuul/zuul-client master: Add encrypt subcommand https://review.opendev.org/750709 | 18:20 |
openstackgerrit | Matthieu Huin proposed zuul/zuul-client master: Add Dockerfile https://review.opendev.org/755519 | 18:20 |
corvus | mhu: you can drop the whole arch section | 18:20 |
openstackgerrit | Matthieu Huin proposed zuul/zuul-client master: Add Dockerfile https://review.opendev.org/755519 | 18:21 |
mhu | corvus: there you go | 18:21 |
corvus | tobiash: https://review.opendev.org/755519 is ready for +3 | 18:21 |
clarkb | corvus: if you're reviewing things https://review.opendev.org/#/c/761229/ would be good to rereview (I cleaned up logging since you last reviewed it) | 18:23 |
mhu | thanks for the reviews, it's good to see that stuff getting merged! :) | 18:24 |
corvus | clarkb: +3 mhu: sorry for the delay :) | 18:25 |
tobiash | corvus: added a question | 18:26 |
corvus | tobiash: right my fault; i undid the TODO comments wrong there | 18:28 |
corvus | tobiash, mhu: i'll fix | 18:28 |
fungi | awesome that we've made it so easy to build multi-arch images you can even do it by accident ;) | 18:28 |
openstackgerrit | James E. Blair proposed zuul/zuul-client master: Add Dockerfile https://review.opendev.org/755519 | 18:29 |
*** zenkuro has quit IRC | 18:38 | |
*** zenkuro has joined #zuul | 18:38 | |
openstackgerrit | Merged zuul/zuul-client master: Add Dockerfile https://review.opendev.org/755519 | 18:45 |
openstackgerrit | Merged zuul/zuul master: REST API: improve tenant scoping of autohold, authorizations https://review.opendev.org/728118 | 18:58 |
*** zenkuro has quit IRC | 19:02 | |
openstackgerrit | Merged zuul/nodepool master: Have nodepool scan as many ssh host keys as possible https://review.opendev.org/761229 | 19:14 |
clarkb | I'll restart an opendev launcher after lunch to ensure ^ is happy in prod andnot just testing | 19:16 |
fungi | thanks, i guess we also have users who can confirm it fixes the problem of nodes switching between host key types | 19:25 |
clarkb | ya | 19:28 |
*** vorotech has joined #zuul | 20:19 | |
sean-k-mooney | should depends on work between different triggers? | 21:08 |
sean-k-mooney | e.g. can a github PR depend on a gerrit reivew | 21:08 |
fungi | yes | 21:08 |
fungi | as long as those projects are included in the same tenant | 21:08 |
sean-k-mooney | did i do this wrong so https://github.com/SeanMooney/zuul-test/pull/4/commits | 21:09 |
sean-k-mooney | am they are | 21:09 |
fungi | cross-connection change/pr/mr dependencies should totally work | 21:09 |
clarkb | even if they are different tenants it will still work as far as preventing one from merging before the other goes | 21:10 |
clarkb | I think | 21:10 |
sean-k-mooney | i wonder is this a branch thing http://paste.openstack.org/show/799803/ is my tenant config | 21:11 |
sean-k-mooney | oh | 21:11 |
tobiash | sean-k-mooney: under github the depends on must be in the pr description, not commit message | 21:11 |
sean-k-mooney | coudl it be the load-branch... acutlly no | 21:11 |
sean-k-mooney | tobiash: oh i did not know that | 21:12 |
sean-k-mooney | is that documetned somewhere | 21:12 |
* sean-k-mooney not that i read it too closely | 21:12 | |
tobiash | https://zuul-ci.org/docs/zuul/discussion/gating.html#cross-project-dependencies | 21:13 |
sean-k-mooney | ah yes its in the note which i did not read | 21:14 |
sean-k-mooney | :) | 21:14 |
sean-k-mooney | so like https://github.com/SeanMooney/zuul-test/pull/5 | 21:15 |
sean-k-mooney | yep got a node failure which is fine i dont have that label set up yet | 21:16 |
corvus | sean-k-mooney: congrats, you just did cross-source-dependencies :) | 21:21 |
sean-k-mooney | hehe yep is there a reason it does not work in the commit by the way | 21:22 |
sean-k-mooney | i mean its fine just wondering why not support both | 21:22 |
fungi | because zuul isn't triggered per commit for github, it's triggered by pull request, and also going back and altering commit messages in arbitrary commits within pull requests is frowned upon in some github workflows | 21:25 |
sean-k-mooney | ah right | 21:26 |
sean-k-mooney | that makes sense when you say it | 21:26 |
corvus | (you can put it in both of course, it'll just be ignored in the commit; if you do the github default of making the pr description from the commit, then that makes it easy) | 21:26 |
sean-k-mooney | yep i forgot to add it the first time then force pushed and then didnt see how to update the description | 21:27 |
sean-k-mooney | so i just created a second pr which auto populated and it worked | 21:27 |
sean-k-mooney | personally i dont really like the PR workflow unless you treat it like gerrit and fix the change and force push the fixed version | 21:28 |
sean-k-mooney | i really hate the add patches on top to adress feedback appoch and just squash them | 21:28 |
sean-k-mooney | both have advantages in a way just personal prefrenece really | 21:29 |
fungi | i'm with you on that, but to each their own | 21:30 |
fungi | for better or for worse, github and its related workflows have dominated open source development mindshare in recent years, so anything which deviates from that is considered cumbersome or hard to understand | 21:32 |
corvus | i force-push updates to PRs when asked to make changes in review. no one has yelled at me yet. | 21:42 |
clarkb | the downside to that is github doesn't retain the old commits | 21:42 |
clarkb | they do keep the old comments and diff contexts now though | 21:42 |
clarkb | prior to that change some people would complain if you force pushed over as a lot of review context would be lost | 21:43 |
sean-k-mooney | ya but that a failing of github not really your use of it | 21:46 |
*** vorotech has quit IRC | 21:50 | |
*** vorotech has joined #zuul | 21:54 | |
*** vorotech has quit IRC | 21:55 | |
*** rfolco has quit IRC | 22:14 | |
openstackgerrit | Brian Haley proposed zuul/zuul-jobs master: Decrease MTU to account for IPv6 header https://review.opendev.org/761800 | 22:35 |
avass | tobiash: re 747865, does changing job definition for a parent job cause a child job to run? | 22:55 |
avass | looks like most of the other jobs doesn't specify it's parent in files: | 22:55 |
corvus | avass: supposed to (basically it's based on the serialization of the job) | 22:56 |
avass | okay good to know | 22:56 |
openstackgerrit | Albin Vass proposed zuul/zuul-jobs master: Add nimble roles and job https://review.opendev.org/747865 | 22:57 |
clarkb | I've just noticed that we didn't run a docker image promote in opendev land because we didn't match file matchers on the chagne that updated the image. The chagne that updated the image did so by updating the job parameters for the image builds. Is there a way of expressing "please always run this job in pipeline foo if a job in pipeline bar ran" ? | 22:59 |
clarkb | in this case I think not because it also depends on the merge events? but it would be nice to be able to drop the fiel matchers from the promote job and trigger it via "the image build succeeded and the change landed" somehow | 22:59 |
openstackgerrit | Albin Vass proposed zuul/zuul-jobs master: Remove unecessary files attributes from child jobs https://review.opendev.org/761802 | 23:00 |
corvus | clarkb: i'm wondering if we should consider "lots of disparate images in one repo" an anti-pattern for reasons like this | 23:01 |
corvus | clarkb: that's just a thought. i don't have an immediate solution to the problem you pose. | 23:01 |
openstackgerrit | Albin Vass proposed zuul/zuul-jobs master: Remove unecessary files attributes from child jobs https://review.opendev.org/761802 | 23:02 |
avass | corvus: how about we clean that up a bit? ^ | 23:02 |
clarkb | ya its also not critical for us in opendev right now. Mostly bringing it up as a thing that would be good to address if possible | 23:02 |
clarkb | It was for intermediate images in a gerrit upgrade path that we'll never really use in production. The updates were minor too | 23:02 |
corvus | clarkb: it may theoretically be possible; something like a soft dependency on an artifact. | 23:02 |
corvus | (since the image-upload job produces an artifact) | 23:03 |
clarkb | corvus: oh ya we can still trigger on the merge action but then run jobs based on artifact prsence? | 23:03 |
corvus | clarkb: well, yes, but to be clear: i was suggesting a zuul enhancement to allow you to essentially have a file matcher for artifacts. but having said that, today you could probably do a zero-node job to check if the artifact exists and use that to decide whether to run a child job that does the promote. | 23:04 |
*** hamalq has joined #zuul | 23:05 | |
corvus | (the data and queries are all there to do that -- they're used to find dependent images for provides/requires) | 23:06 |
clarkb | interesting. If I ever find time I may try implementing that | 23:06 |
openstackgerrit | Albin Vass proposed zuul/zuul-jobs master: Add option to install kubernetes with kind https://review.opendev.org/740935 | 23:06 |
avass | anyone wanna approve: https://review.opendev.org/#/c/760691/ so zbr can work on 208 easier without the warnings piling up faster than anyone can fix them? | 23:09 |
clarkb | avass: did the new release to address my concern happen? | 23:10 |
corvus | should that pin to 4.3.7? | 23:10 |
corvus | (since that addresses a concern from ianw) | 23:11 |
clarkb | oh ya I think if that is the change that fixes is the archive concern then ya | 23:11 |
clarkb | and it also addresses ianw's concern | 23:11 |
clarkb | ++ to that then I think we can land it | 23:11 |
avass | sure I'll update it | 23:12 |
openstackgerrit | Albin Vass proposed zuul/zuul-jobs master: DNM: Add unified synchronize-repos role that works with linux and windows https://review.opendev.org/740005 | 23:12 |
avass | tobiash: squashed ^ with the change I had on top of it | 23:12 |
openstackgerrit | Albin Vass proposed zuul/zuul-jobs master: Enable progressive mode with ansible-lint https://review.opendev.org/760691 | 23:14 |
openstackgerrit | Albin Vass proposed zuul/zuul master: install-js-tools: add support for manjaro https://review.opendev.org/761803 | 23:19 |
corvus | til manjaro is an arch derivative. avass are you using that? | 23:37 |
fungi | i've got a good friend who uses manjaro too, or at least did until recently | 23:40 |
avass | yup | 23:41 |
* avass am using arch btw | 23:42 | |
fungi | ahh, yeah, friend said he switched to ubuntu a couple weeks back after years on manjaro (decided it was too much fiddly maintenance) | 23:42 |
avass | :) | 23:42 |
avass | manjaro is way less fiddly maintanence compared to arch though | 23:42 |
fungi | i'm not one to talk, i run a mix of debian/unstable and openbsd/current | 23:43 |
fungi | i probably suffer from some computing-oriented form of masochism | 23:45 |
avass | oh you should try out windows then | 23:45 |
clarkb | hahaha | 23:46 |
fungi | niiiice | 23:47 |
openstackgerrit | Merged zuul/zuul-jobs master: Enable progressive mode with ansible-lint https://review.opendev.org/760691 | 23:49 |
avass | is it just me or is review.opendev.org behaving strange? | 23:51 |
fungi | can you qualify "strange"? | 23:52 |
avass | that ^ change got merged but it doesn't show up as merged, or has any reviews. gonna check with a different computer | 23:53 |
clarkb | I don't see that | 23:53 |
fungi | i see it merged with reviews | 23:53 |
clarkb | could be an issue between client and server caused that request for data to fail? | 23:54 |
fungi | load average on review.o.o isn't low right now, but isn't heavy either | 23:54 |
fungi | load average under 3 on a 16-way smp server | 23:55 |
avass | looks like it's just this computer for some reason | 23:55 |
corvus | time for a new computer | 23:56 |
avass | also cannot download changes :( | 23:56 |
fungi | suddenly broken ipv6 on that machine maybe? | 23:56 |
corvus | avass: or maybe your computer is telling you it's friday evening :) | 23:56 |
avass | I bought it today heh :) | 23:56 |
corvus | avass: it should be in the return window! "This computer is broken! It doesn't download changes!" | 23:57 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!