| *** rfolco|rover has joined #zuul | 00:04 | |
| *** rfolco|rover has quit IRC | 00:09 | |
| *** swest has quit IRC | 01:50 | |
| *** Goneri has quit IRC | 01:53 | |
| *** swest has joined #zuul | 02:04 | |
| *** saneax has quit IRC | 03:02 | |
| *** zxiiro has quit IRC | 03:03 | |
| *** evrardjp has quit IRC | 04:36 | |
| *** evrardjp has joined #zuul | 04:36 | |
| *** sgw has quit IRC | 06:13 | |
| *** jpena|off has quit IRC | 07:18 | |
| *** jpena|off has joined #zuul | 07:19 | |
| *** avass has joined #zuul | 07:31 | |
| openstackgerrit | Andreas Jaeger proposed zuul/zuul-jobs master: Revert "Revert "ensure-tox: use venv to install"" https://review.opendev.org/726413 | 08:33 |
|---|---|---|
| openstackgerrit | Albin Vass proposed zuul/zuul master: Update to create-react-app 3.4.1 https://review.opendev.org/716305 | 09:03 |
| *** tosky has joined #zuul | 09:29 | |
| avass | mordred: I feel like I'm learning react the hard way. But I have some wild guesses about what's going on. This is the error we get: https://reactjs.org/docs/error-decoder.html/?invariant=130&args[]=undefined&args[]= from line 21 in src/actions/configErrors.js | 09:45 |
| avass | mordred: and since the dispatch function seems related to redux: https://redux.js.org/api/store#dispatchaction my guess is that something similar to the test cases is going on where a class component has been turned into a function component somewhere | 09:46 |
| avass | and that causes strange happenings :) | 09:48 |
| veecue | Can someone help me understand how line-comments are submitted to gerrit for the tox-linters? | 10:51 |
| openstackgerrit | Albin Vass proposed zuul/zuul master: Update to create-react-app 3.4.1 https://review.opendev.org/716305 | 10:54 |
| avass | veecue: depends on which part you're interested in :) | 10:55 |
| avass | veecue: if you just need to know how to use zuul_return to return line number you can take a look at this: https://opendev.org/zuul/zuul-jobs/src/branch/master/roles/tox/tasks/main.yaml#L57 | 10:59 |
| avass | uuh, file comments | 10:59 |
| openstackgerrit | Albin Vass proposed zuul/zuul master: Update to create-react-app 3.4.1 https://review.opendev.org/716305 | 11:01 |
| veecue | avass: Are the line comments part of the file comments? And mostly I'm interested in it from the driver side, since it is not really documented in the gerrit driver. | 11:06 |
| avass | veecue: ah, yeah I don't know how that works inside zuul | 11:07 |
| avass | mordred: I'm so confused, according to the ES6 spec we are missing a semicolon in the export, but npm lint is complaining when i add a semicolon :( | 11:09 |
| openstackgerrit | Albin Vass proposed zuul/zuul master: Update to create-react-app 3.4.1 https://review.opendev.org/716305 | 11:10 |
| openstackgerrit | Justus proposed zuul/zuul master: more work towards a working gitea driver https://review.opendev.org/726391 | 13:07 |
| *** avass has quit IRC | 13:22 | |
| openstackgerrit | Justus proposed zuul/zuul master: more work towards a working gitea driver https://review.opendev.org/726391 | 13:29 |
| fungi | veecue: it relies on the line property of the set review method in gerrit's rest api: https://gerrit-review.googlesource.com/Documentation/rest-api-changes.html#set-review | 13:33 |
| veecue | ok. Gitea allows for a similar API. But how are the lines passed from Zuul to the Reporter driver? That's the point, I was missing | 13:34 |
| corvus | veecue: the reporter class has a getFileComments method; you'll want to call that, then probably transform the results into the data structure that gitea is expecting. the github driver is a good example of this | 13:39 |
| veecue | corvus, fungi: Thank you! | 13:40 |
| fungi | yeah, i had to go hunting for it as well, some of that got refactored after it was added, i guess to abstract it a bit for use by the github driver | 13:41 |
| corvus | veecue: i just started up a local zuul talking to a local gitea and verified basic connectivity with your changes :) | 13:48 |
| veecue | :) I'm currently integrating it into my production gitea to test a few real-life applications | 13:52 |
| openstackgerrit | Merged zuul/zuul master: Remove dmsimard from zuul-jobs maintainers https://review.opendev.org/726432 | 14:08 |
| *** dustinc has quit IRC | 14:14 | |
| corvus | veecue: i think we need some updates to giteapy to support branch protection. i'm planning on re-running the swagger code generator to update it. before i get too far: does that sound right to you? | 14:37 |
| veecue | Already did it ;) | 14:39 |
| corvus | veecue: glad i asked :) do you have a pr for that? | 14:40 |
| veecue | https://pastebin.com/5Gd8juqL | 14:40 |
| veecue | corvus: I wasn't sure whether we should try to update upstream giteapy or just include our own in the zuul repo, that's why I only built it for my dev environment. Have to change my car's tires now, feel free to use the script and properly include it somewhere | 14:42 |
| corvus | i bet we can update giteapy, i'll take a look at that | 14:42 |
| *** avass has joined #zuul | 14:46 | |
| *** zenkuro has quit IRC | 15:14 | |
| corvus | veecue: it's not small -- https://github.com/dblueai/giteapy/pull/2 | 15:19 |
| openstackgerrit | Albin Vass proposed zuul/zuul master: Update to create-react-app 3.4.1 https://review.opendev.org/716305 | 15:38 |
| veecue | corvus: yeah, but mostly cosmetic changed due to the new swagger-gen version. Why do you want to have the Branchprotection API? | 15:40 |
| corvus | veecue: to support the workflow where people use development branches on the target repo itself (rather than forks of the repo) -- there's some description here for the github driver: https://zuul-ci.org/docs/zuul/reference/drivers/github.html#branch-protection-rules | 15:46 |
| openstackgerrit | Albin Vass proposed zuul/zuul master: Update to create-react-app 3.4.1 https://review.opendev.org/716305 | 15:52 |
| openstackgerrit | James E. Blair proposed zuul/zuul master: Support exclude-unprotected-branches https://review.opendev.org/726540 | 15:53 |
| corvus | veecue: ^ that works with the updated giteapy | 15:53 |
| openstackgerrit | James E. Blair proposed zuul/zuul master: Support exclude-unprotected-branches https://review.opendev.org/726540 | 15:54 |
| veecue | corvus: Oh and from there we can also get the required number of approvals to calculate whether we can gate | 15:55 |
| corvus | veecue: yep | 15:56 |
| veecue | other question: how can I tell zuul to run in a sub-url of a domain instead of /? | 15:57 |
| fungi | as in zuul-web? (status api, dashboard....) | 15:58 |
| corvus | veecue: https://zuul-ci.org/docs/zuul/howtos/installation.html#sub-directory-serving | 15:58 |
| veecue | Thanks! | 15:59 |
| corvus | there are several other options there too; here's the overview: https://zuul-ci.org/docs/zuul/howtos/installation.html#web-deployment-options | 16:00 |
| veecue | apparently that first link was outdated. I didn't find any "homepage" option in the package.json | 16:02 |
| corvus | tristanC, mordred: ^ | 16:03 |
| corvus | veecue: it might be worth trying the rest of the instructions and ignoring that for now -- maybe that's no longer necessary | 16:07 |
| mordred | corvus: oh yeah - we need to update that - we do not need to set the homepage setting any longer | 16:09 |
| veecue | corvus: I'm doing almost the same thing with nginx. API and everything works. But assets are still tried to be loaded from "/". Used REACT_APP_ZUUL_API as a workaround | 16:10 |
| veecue | mordred: How do I set the prefix then? The files still point to "/" | 16:11 |
| mordred | hrm. I didn't think we needed to do that any longer | 16:16 |
| * mordred pokes | 16:18 | |
| mordred | veecue: tristanC would definitely know the answer here - he runs his on a suburl in production | 16:19 |
| mordred | hrm. so - https://opendev.org/zuul/zuul/src/branch/master/web/src/api.js#L26 also says package.json needs to be updated | 16:23 |
| corvus | it apparently disappeared in https://review.opendev.org/607479 (it was in the original react patch, but not in the re-do after we reverted it) | 16:26 |
| openstackgerrit | Albin Vass proposed zuul/zuul master: Update to create-react-app 3.4.1 https://review.opendev.org/716305 | 16:28 |
| avass | mordred: do you know if it's possible to reproduce that error locally somehow? | 16:30 |
| mordred | avass: you'd need a zuul with a config error in a tenant | 16:31 |
| avass | mordred: so not without some effort :) | 16:31 |
| corvus | but you can use the api env var to point at a running instance with an error | 16:31 |
| avass | corvus: doesn't yarn start:multi do that? because the error doesn't appear when i do that | 16:32 |
| mordred | https://zuul.opendev.org/t/zuul/status ... the opendev zuul tenant has config errors | 16:32 |
| mordred | avass: try start:opendev | 16:32 |
| mordred | and then browse to the zuul tenant | 16:32 |
| avass | I'll check | 16:32 |
| mordred | you should see the page go blank | 16:32 |
| avass | I've been using the fedora tenant, but that doesn't error locally | 16:33 |
| mordred | oh - interesting - the fedora tenant totally breaks with the published site preview link doesn't it | 16:34 |
| avass | yeah | 16:35 |
| tristanC | veecue: corvus: it seems like we are using `PUBLIC_URL=/zuul/ ./node_modules/.bin/yarn build` to get a zuul-web working in a `/zuul` sub url, from: https://softwarefactory-project.io/cgit/rpms/zuul/tree/zuul.spec#n203 | 16:36 |
| *** evrardjp has quit IRC | 16:36 | |
| *** evrardjp has joined #zuul | 16:36 | |
| avass | mordred: I think the response data ins the fetchConfigErrorsAction for some reason: https://opendev.org/zuul/zuul/src/branch/master/web/src/actions/configErrors.js#L22 | 16:36 |
| avass | that's supposed to say '...is undefined...' :) | 16:37 |
| mordred | avass: it shouldn't matter - but we're using the npm role in playbooks/dashboard/run.yaml instead of the yarn role | 16:37 |
| mordred | avass: so maybe we should update the job to use yarn - perhaps using npm it's ignoring yarn.lock in the repo and calculating its own deps and it's different than what we're getting using yarn | 16:38 |
| mordred | avass: because I agree - it's working for me locally | 16:38 |
| avass | mordred: yeah, start:opendev works as well | 16:38 |
| mordred | let's update that then | 16:38 |
| openstackgerrit | Justus proposed zuul/zuul master: executor: Catch error when reading cpu_times https://review.opendev.org/726545 | 16:39 |
| openstackgerrit | Albin Vass proposed zuul/zuul master: Update to create-react-app 3.4.1 https://review.opendev.org/716305 | 16:41 |
| veecue | tristianC: Thank you! Maybe the documentation should be updated with that ;) | 16:42 |
| openstackgerrit | Albin Vass proposed zuul/zuul-jobs master: DNM: test building dashboard with yarn https://review.opendev.org/726546 | 16:44 |
| openstackgerrit | Albin Vass proposed zuul/zuul master: Update to create-react-app 3.4.1 https://review.opendev.org/716305 | 16:44 |
| veecue | tristianC still does not work... Now the assets get loaded correctly, but the API is still tried to be reached from / | 16:50 |
| openstackgerrit | Albin Vass proposed zuul/zuul-jobs master: DNM: test building dashboard with yarn https://review.opendev.org/726546 | 16:50 |
| mordred | avass: I'm going down a smidge of a rabbithole here ... | 16:55 |
| mordred | avass: I just realized how many of our npm jobs are super npm specific | 16:55 |
| mordred | so I'm gonna fix that | 16:55 |
| mordred | also - we dont seem to run ensure-nodejs in any of our javascript jobs | 16:55 |
| tristanC | veecue: that's odd, here is how the zuul api url is discovered: https://opendev.org/zuul/zuul/src/branch/master/web/src/api.js#L96 | 16:57 |
| mordred | avass: oh - we _do_ run ensure-nodejs in the jobs. that's good at least | 17:00 |
| avass | mordred: using the yarn role did not fix it hmm | 17:02 |
| openstackgerrit | Monty Taylor proposed zuul/zuul-jobs master: Support using yarn instead of npm in npm jobs https://review.opendev.org/726547 | 17:06 |
| mordred | avass: weird | 17:07 |
| mordred | well - ^^ that should at least update _all_ of our zuul jobs to use yarn instead of npm :) | 17:07 |
| avass | mordred: should we run yarn in the npm role? | 17:08 |
| avass | mordred: feels weird | 17:08 |
| mordred | avass: I mean - the other option is to make analog jobs for every javascript job we have | 17:09 |
| mordred | becuaes they all juse use npm right now even for yarn projects | 17:09 |
| mordred | maybe there's a more generic name we could use | 17:09 |
| mordred | (yarn is a mostly drop-in replacement, other than the whole yarn.lock thing) | 17:09 |
| avass | mordred: maybe the name just shouldn't be 'npm' if we might be running yarn instead | 17:09 |
| mordred | yeah | 17:10 |
| mordred | like: build-javascript-content-tarball for instance | 17:10 |
| mordred | that's a great generic job - and for us now it's currently using npm and not yarn | 17:10 |
| mordred | I'm not sure what the generic term is for "npm or yarn" :( | 17:10 |
| mordred | avass: ok - what about this - what about make the role "js-package-manager" (slightly ugly) - have it do yarn vs npm | 17:11 |
| mordred | avass: have the yarn and npm roles use it with overrides set | 17:12 |
| mordred | avass: but have the jobs in tree use it instead | 17:12 |
| mordred | avass: and then make jobs like nodejs-npm that is named something else | 17:12 |
| mordred | like maybe "nodejs-build" or something | 17:12 |
| * mordred works on patch | 17:13 | |
| mordred | avass: oh- or not nodejs-buiold - what about just "js-build" or "javascript-build" | 17:14 |
| avass | yeah, that sounds like a plan :) | 17:14 |
| *** tumble has joined #zuul | 17:17 | |
| mnaser | corvus, mordred: our CI is now reporting to zuul/zuul-jobs (see: https://review.opendev.org/#/c/726547/1) and it's already blowing up from what looks like missing bindeps | 17:29 |
| mnaser | cc noonedeadpunk ^ | 17:29 |
| mnaser | configure: error: no acceptable C compiler found in $PATH | 17:32 |
| AJaeger | thanks, mnaser for setting that up. | 17:32 |
| mnaser | AJaeger: just noticed sql reporter wasnt setup so the build pages are 404-ing but just fixed that now | 17:32 |
| AJaeger | mnaser: once you have the bindeps running, please test https://review.opendev.org/726413 - recheck should be enough | 17:33 |
| avass | mordred: I've been stepping through everything with the debugger and it looks like it fails somewhere inside redux/react. So problems with dependencies sounds probable | 17:33 |
| openstackgerrit | Mohammed Naser proposed zuul/zuul-jobs master: bindep: add gcc https://review.opendev.org/726549 | 17:35 |
| avass | mnaser: is there a reason why that should be in a bindep instead of the role? | 17:37 |
| mnaser | avass: because the job that's failing is the tox-pyXX jobs | 17:37 |
| mnaser | so the actual 'creation' of the tox venv fails because we have dependencies inside zuul-jobs that cant be built | 17:38 |
| fungi | mnaser: as to why, my expectation is that we're using some python dependencies which require c extensions and aren't published on pypi as wheels for the relevant platforms, so in opendev the prebuilt wheel cache is masking the missing dependencies | 17:39 |
| mnaser | fungi: that explains things | 17:40 |
| avass | mnaser: so that's specific for those environments? | 17:41 |
| AJaeger | mnaser: yeah, py27 testing for vexxhost succeeded ;) | 17:42 |
| mnaser | nope, its just that opendev has a prebuilt wheel for it (and we don't) so the jobs pass upstream and don't pass here. any other user that's not opendev would likely fail to have those wheel build | 17:42 |
| mnaser | yep but now another challenge.. "Python.h: No such file or directory" -- when using pyenv.. | 17:42 |
| AJaeger | py35 fails with "ERROR: ansible-lint 4.3.0a0 has requirement ansible>=2.8, but you'll have ansible 2.6.20 which is incompatible." | 17:42 |
| mnaser | this is weird: /home/zuul/src/opendev.org/zuul/zuul-jobs/.tox/py35/include/site/python3.7/netifaces | 17:43 |
| mnaser | (we use the pyenv ensure-python stuff) | 17:43 |
| AJaeger | Ah, ansible is not the real failure | 17:43 |
| AJaeger | you need python-devel as well | 17:44 |
| mnaser | AJaeger: i don't think so, because in this case, the headers come from pyenv | 17:44 |
| mnaser | i think the issue is that it's using the system-provisioned python, not the one that pyenv installed | 17:44 |
| AJaeger | oh fun | 17:45 |
| mnaser | hence why it ran py35 target in python 3.7 (debian) | 17:45 |
| mnaser | ah damn | 17:45 |
| mnaser | we run ensure-python *after* ensure-tox | 17:45 |
| mnaser | so we end up installing python *after* installing tox, which means it already installed tox with system python | 17:45 |
| AJaeger | mnaser: I suggest you use "gcc [test]" for bindep.txt | 17:48 |
| openstackgerrit | Mohammed Naser proposed zuul/zuul-jobs master: bindep: add gcc https://review.opendev.org/726549 | 17:49 |
| mnaser | AJaeger: done :) | 17:49 |
| openstackgerrit | Mohammed Naser proposed zuul/zuul-jobs master: tox: run ensure-python first https://review.opendev.org/726550 | 17:49 |
| AJaeger | that was quick, mnaser ;) | 17:49 |
| mnaser | AJaeger: wanted to push it before the ensure-python swap patch :P | 17:50 |
| mnaser | to avoid the "oops dependency broke" | 17:50 |
| openstackgerrit | Justus proposed zuul/zuul master: executor: Catch error when reading cpu_times https://review.opendev.org/726545 | 17:50 |
| AJaeger | mnaser: still your CI is confused ;( | 17:50 |
| mnaser | hm | 17:51 |
| mnaser | this has been a repeat issue i've been unable to pin down :\ | 17:51 |
| AJaeger | is that a problem with depends-on? What if you stack them on top of each other? | 17:52 |
| mnaser | 2020-05-09 17:52:19,587 INFO zuul.Pipeline.opendev.third-party-ci: Unable to merge change <Change 0x7fac2c23de20 zuul/zuul-jobs 726550,1> | 17:53 |
| mnaser | yeah it seems completetly hard locked | 17:56 |
| mnaser | even if the depends is not in gate | 17:56 |
| openstackgerrit | Mohammed Naser proposed zuul/zuul-jobs master: tox: run ensure-python first https://review.opendev.org/726550 | 17:56 |
| mnaser | https://www.irccloud.com/pastebin/uqzW5t4N/ | 17:58 |
| mordred | mnaser: weird - those two patches look good though | 17:59 |
| mnaser | mordred: and opendev's zuul was happy | 18:00 |
| mnaser | i guess i can look at merger logs | 18:00 |
| mordred | corvus: workoing on some updates to javascript jobs - made me think - what if we defined a zuul job parameter "deprecated" that would allow setting a message that zuul would return as a comment (assumign it's configured to commnent) on any run of that job or any of its children? | 18:00 |
| mnaser | interesting, 2/3 mergers have a bunch of "Updating local repository" in the logs, but one of them is absolutely silence | 18:01 |
| avass | mordred: what if we could return a warning from any job | 18:02 |
| AJaeger | mordred: so, if a job uses role X and that role X is marked deprecated, it would comment on that one? Yeah, we discussed that in the context of moving from install-X to ensure-X - but nobody acted on it so far. | 18:02 |
| AJaeger | mordred: also, marking jobs directly as deprecated would be great... | 18:02 |
| mordred | yeah - there's two things here ... | 18:02 |
| mnaser | oh no no no | 18:03 |
| mnaser | our tox-py38 jobs have been lying to us | 18:03 |
| mordred | mnaser: AWESOME | 18:03 |
| mnaser | /usr/local/lib/python3.6/dist-packages/tox/config/__init__.py:600: UserWarning: conflicting basepython version (set 3.6, should be 3.8) for env 'py38';resolve conflict or set ignore_basepython_conflict | 18:03 |
| mnaser | (thats opendev) | 18:03 |
| mnaser | mine just failed with py38 with "ModuleNotFoundError: No module named '_ctypes'" | 18:03 |
| AJaeger | or going further: What about making the openstack-train-python-jobs deprecated on master only? | 18:03 |
| mordred | mnaser: because of the install python ordering | 18:03 |
| avass | mnaser: I believe we had some problems with deleted tags/branches a long time ago and the mergers got stuck in a loop | 18:03 |
| mnaser | mordred: im not sure yet. https://0db61f2fe1de63c8170b-7716d10619577c42ab1386a760b8bb5c.ssl.cf5.rackcdn.com/726550/1/check/tox-py38/9422faf/job-output.txt | 18:04 |
| mnaser | i see /usr/local/lib/python3.6/dist-packages/tox/config/__init__.py:600: UserWarning: conflicting basepython version (set 3.6, should be 3.8) for env 'py38';resolve conflict or set | 18:04 |
| AJaeger | mnaser: zuul-jobs hsould install the correct python interpreter | 18:04 |
| mordred | AJaeger avass: one is ansible content indicating that it's deprecated (like the roles) - so a way to zuul_return a warning would be great. the other is a job definition itself where there might not be specific python content that needs to return a warning, where a job attribute could be very useful | 18:04 |
| mnaser | ok this job is going to fail 3 times because its failing in pre | 18:05 |
| mordred | mnaser: neat | 18:05 |
| mnaser | but im failing to install tox under python3.8 with ModuleNotFoundError: No module named '_ctypes' | 18:05 |
| mnaser | https://stackoverflow.com/questions/27022373/python3-importerror-no-module-named-ctypes-when-using-value-from-module-mul | 18:05 |
| AJaeger | mordred: agreed | 18:05 |
| mnaser | apparnetly you need libffi-dev | 18:05 |
| avass | mordred: You could always add a 'pre' with a deprecation warning for a specific job if we can return warnings | 18:05 |
| AJaeger | avass: a magic role "job-is-deprecated"? Neat | 18:06 |
| mordred | oh good point - we could even just put deprecations in a base pre playbook and have it do nothing if a variable isn't set | 18:06 |
| mordred | mnaser: we need libffi-dev or just libffi? I'm guessing -dev - yeah | 18:07 |
| mnaser | mordred: i think -dev, but only when using pyenv it seems | 18:08 |
| mordred | mnaser: oh gross | 18:08 |
| AJaeger | mordred, mnaser let's copy from https://opendev.org/zuul/zuul/src/branch/master/bindep.txt#L27-L31 | 18:08 |
| mnaser | AJaeger, mordred: i think we _only_ might need it for pyenv only | 18:09 |
| mordred | mnaser: that makes me think in your case you might want to start making tox installs in stow as well - perhaps in each of your pyenv stow dirs | 18:09 |
| mnaser | so we would add it into the role | 18:09 |
| mordred | so that if you pull a python from pyenv from stow, the ensure-tox would wind up being a no-op | 18:09 |
| mnaser | mordred: yeah the infra is there but we haven't gotten around actually getting the images to ship python from stow (yet) | 18:09 |
| mnaser | i could probably add the element though.. | 18:09 |
| mordred | ah - nod | 18:09 |
| mnaser | i think all i need to do is just add the element to start with | 18:10 |
| AJaeger | I'll sign off again, have a great weekend everybody! | 18:10 |
| mnaser | later, take care AJaeger | 18:10 |
| avass | AJaeger: bye! | 18:10 |
| mordred | mnaser: yeah - for now, maybe just put libffi-dev into the pyenv ensure steps | 18:11 |
| openstackgerrit | Merged zuul/zuul-jobs master: bindep: add gcc https://review.opendev.org/726549 | 18:11 |
| openstackgerrit | Merged zuul/zuul-jobs master: tox: run ensure-python first https://review.opendev.org/726550 | 18:11 |
| zbr | AJaeger: re ansile-lint prepare for more changes, in less than a week from now it will require py>=3.6, already master does. | 18:11 |
| zbr | but, one should not confuse ansible version requirement from linter with the range supported by the code. | 18:11 |
| avass | zbr, mordred: we were planning on dropping support for py35 right? | 18:11 |
| mordred | avass: well ... that woudl be zuul, not zuul-jobs | 18:12 |
| zbr | i am sure nobody lints with a matrix of pythons and ansible versions anyway ;) | 18:12 |
| mordred | we _definitely_ have to support 3.5 in zuul jobs all the way to EOL - and probably a good idea to do our best in zuul-jobs even past that | 18:12 |
| mordred | yah - the base python in tox used for ansible-lint shouldn't matter much | 18:12 |
| openstackgerrit | Mohammed Naser proposed zuul/zuul-jobs master: pyenv: install libffi-dev https://review.opendev.org/726552 | 18:13 |
| avass | oh, yeah that's true | 18:13 |
| zbr | mordred: super. i just wanted to be sure everyone knows that. | 18:13 |
| avass | I'll go back to debugging :) | 18:13 |
| zbr | in fact I think we should consider seriously testing zuul-jobs with newest release of ansible all the time. | 18:14 |
| zbr | we should have lower-upper bound testing to avoid additional bumping costs | 18:14 |
| avass | yeah | 18:14 |
| veecue | tristianC: seems like that only the info endpoint is flawed. When I navigate to the tenant manually, everything works | 18:16 |
| openstackgerrit | Monty Taylor proposed zuul/zuul-jobs master: Add new non-npm specific javascript jobs https://review.opendev.org/726547 | 18:17 |
| mordred | avass: ^^ | 18:17 |
| mordred | mnaser: did you see AJaeger's comment on your latest patch? | 18:19 |
| mnaser | mordred: ah yeah, that's useful, waiting to see if it passes py38 in my env before restarting it | 18:20 |
| mordred | mnaser: cool | 18:20 |
| mnaser | seems to have gotten past that issue | 18:20 |
| mnaser | mordred: it seems to have failed for other reasons (that seem to tell me tox-py38 in opendev isnt that accurate?) | 18:22 |
| mnaser | AttributeError: module 'cgi' has no attribute 'escape' | 18:22 |
| mnaser | ill push that up anyways because thats a fix | 18:22 |
| openstackgerrit | Mohammed Naser proposed zuul/zuul-jobs master: pyenv: install libffi-dev https://review.opendev.org/726552 | 18:22 |
| mnaser | python 3.8 removed cgi.escape | 18:23 |
| mnaser | https://github.com/python/cpython/pull/7662 | 18:23 |
| mnaser | so that 100% confirms opendev is running tox-py38 _not_ in py38 :X | 18:24 |
| avass | mordred: why do we default to node_version 6? | 18:24 |
| mnaser | avass: i think that might have been leftover. i meant to bump that upstream to the latest lts after notifying ML, but never got around it | 18:24 |
| avass | mordred: also, you missed a thing :) | 18:24 |
| openstackgerrit | Monty Taylor proposed zuul/zuul-jobs master: Add new non-npm specific javascript jobs https://review.opendev.org/726547 | 18:25 |
| mordred | avass: good catch! | 18:25 |
| clarkb | mnaser: for the python3.8 jobs to run properly thry have to run on bionic and install the newer python iirc. I epect that step of install newer python is being skipped or failing for some reason | 18:25 |
| clarkb | also you can tell tox to fail if the specified version isnt available (whoch we should do for belts and suspenders) | 18:26 |
| mnaser | clarkb: yeah i think we should do that in zuul/zuul-jobs -- anyways, i'm unsure on how to best fix this | 18:27 |
| fungi | ot looks like we are installing in 3.8: https://review.opendev.org/726288 | 18:27 |
| mnaser | cgi.escape was replaced by html.escape, cgi.escape was deprecated in py3.1 | 18:27 |
| mnaser | but html.escape was added in py3 only | 18:27 |
| mnaser | so while replacing cgi.escape by html.escape will work, it'll work for py3x only | 18:28 |
| fungi | er, https://zuul.opendev.org/t/zuul/build/1bbf4b79169c4b41933145152a9fcf1e/log/tox/py38-0.log | 18:28 |
| fungi | created virtual environment CPython3.8.0.final.0-64 in 655ms | 18:28 |
| fungi | maybe ubuntu is forward-porting cgi.escape to its packaged python? | 18:29 |
| clarkb | https://opendev.org/zuul/zuul-jobs/src/branch/master/roles/ensure-python/tasks/main.yaml#L15 | 18:29 |
| mnaser | fungi: that's a possibility | 18:29 |
| fungi | again, this goes back to the old "what do you want to test" question | 18:30 |
| mnaser | i do see this though: /usr/local/lib/python3.6/dist-packages/tox/config/__init__.py:600: UserWarning: conflicting basepython version (set 3.6, should be 3.8) for env 'py38';resolve conflict or set ignore_basepython_conflict | 18:30 |
| fungi | test against the python interpreters people will likely have on their systems? or test against a custom-compiled upstream cpython? | 18:30 |
| mnaser | yeah | 18:31 |
| clarkb | mnaser: I think that means our tox config is bad | 18:31 |
| clarkb | not that 3.8 isnt availablr | 18:32 |
| openstackgerrit | Monty Taylor proposed zuul/zuul master: Update node to v14 and reorg the jobs a bit https://review.opendev.org/726553 | 18:32 |
| openstackgerrit | Monty Taylor proposed zuul/zuul master: Update to new javascript jobs https://review.opendev.org/726554 | 18:32 |
| fungi | clarkb: then how do you explain the log i linked? | 18:32 |
| clarkb | fungi: hrm ya I dunno how can you have that warning and a 3.8 env? | 18:32 |
| avass | I'm logging off too, bye! | 18:33 |
| clarkb | mnaser: is that warniny from opendev jobs? | 18:33 |
| mnaser | clarkb: yeah, https://7f8143495509f2da98f9-0ee3eeb68aa256c74f1e35f60c262d61.ssl.cf2.rackcdn.com/726552/1/check/tox-py38/51989fa/job-output.txt | 18:33 |
| clarkb | fungi: mnaser's example is from zuul-jobs is yours a zuul-jobs example too? | 18:34 |
| clarkb | https://opendev.org/zuul/zuul-jobs/src/branch/master/tox.ini#L7 that is the issue | 18:35 |
| clarkb | we need to set ignore basepython conflict | 18:35 |
| clarkb | `python3` == python3.6 on bionic | 18:36 |
| fungi | https://7f8143495509f2da98f9-0ee3eeb68aa256c74f1e35f60c262d61.ssl.cf2.rackcdn.com/726552/1/check/tox-py38/51989fa/tox/py38-0.log | 18:37 |
| fungi | yeah, i was looking at zuul/zuul not zuul/zuul-jobs | 18:37 |
| fungi | i agree the tox.ini for zuul-jobs is broken | 18:37 |
| fungi | we should match it to the tox.ini for zuul probably | 18:37 |
| clarkb | fungi: except zuul-jobs supports python2 | 18:38 |
| fungi | ahh | 18:38 |
| mordred | but - arent' we also not actually getting 3.8? | 18:38 |
| mordred | because if we were we'd see the error with cgi.escape | 18:38 |
| mordred | I just checked - it is not in 3.8 on ubuntu bionic | 18:38 |
| clarkb | mordred yes because we use python3 | 18:38 |
| clarkb | python3 is 3.6 on bionic | 18:38 |
| mnaser | fwiw this is my missing cgi.escape failure: https://zuul.vexxhost.dev/t/opendev/build/78238d9ed3c7412d9bf0ad26ffc6476d | 18:38 |
| fungi | mordred: yes, ignore_basepython_conflict = True will solve that, -e py38 will either actually use 3.8 or throw an error because it's missing | 18:39 |
| mordred | oh - because py38 isn't smart enough to use python3.8 even if it's installed? | 18:39 |
| clarkb | if weset ignore base python vonflict the testing should work as expected | 18:39 |
| mordred | clarkb: jesus | 18:39 |
| mordred | ok | 18:39 |
| clarkb | mordred: correctit will if we set ignore basepython conflict | 18:39 |
| mordred | so - we weren't installing 3.8 properly probably, but not noticing it because of basepython conflict | 18:39 |
| fungi | it's tox trying to reconcile you setting basepython to something other than what -e py38 would actually use | 18:39 |
| mordred | so multiple broken things | 18:39 |
| mordred | mnaser: you found a lovely can of worms today! | 18:40 |
| mnaser | lols | 18:40 |
| mnaser | i still need to figure out why my merges are failing :\ | 18:40 |
| mordred | yeah | 18:40 |
| clarkb | this is like the fifth project I've had to debug this for :) | 18:40 |
| mordred | clarkb: you're getting good at it then | 18:41 |
| clarkb | might be worth an email blast I guess | 18:41 |
| mnaser | wild idea | 18:41 |
| mnaser | should we add a simple check for this inside tox job | 18:41 |
| clarkb | mnaser: no | 18:41 |
| mnaser | so it just fails if it detects tox isn't properly configured | 18:41 |
| clarkb | its not our job to tell people how to configure tox | 18:41 |
| clarkb | it could be proper though | 18:41 |
| clarkb | we cant know | 18:41 |
| mnaser | but for example cant tox-py38 job know that it is _not_ running in py38 | 18:42 |
| clarkb | ya that may be desireable for someone since that is how they configured tox | 18:42 |
| fungi | though i think tox upstream has said ignore_basepython_conflict will (eventually) default to True | 18:42 |
| mnaser | sounds like we're letting users shoot themselves in the foot, but eh | 18:42 |
| clarkb | mnaser: no tox is | 18:42 |
| mordred | clarkb: so - ignore_basepython_conflict = True is the thing that will cause tox to blow up if py38 isn't done with python 3.8? | 18:43 |
| clarkb | I think if we start being opinionated about tools like that we start to lose the utility of the tool | 18:43 |
| clarkb | mordred: yes | 18:43 |
| mordred | clarkb: do we also have to add a [py38] section with base python in it? | 18:43 |
| clarkb | mordred: no | 18:43 |
| fungi | basically it works like this: | 18:44 |
| fungi | tox believes when you say -e py38 that you want to use python3.8 | 18:44 |
| fungi | but if you set basepython then it believes you want to use that for *everything* | 18:44 |
| openstackgerrit | Monty Taylor proposed zuul/zuul-jobs master: Set ignore_basepython_conflict to true https://review.opendev.org/726555 | 18:44 |
| mordred | fungi: ah. thank you | 18:45 |
| fungi | and it has trouble reconciling those requests, so trusts the basepython option over the implicit python version from the env name | 18:45 |
| clarkb | what tox is missing is a way to clearly say I want python3 by default even if tox is installed uner python2.7 | 18:45 |
| fungi | ignore_basepython_conflict is used to tell it that if the implicit env version conflicts with the basepython you've set, that's okay | 18:46 |
| clarkb | we can aplroximate that with basepython and ignoring conflicts but it isnt straightforward or clear | 18:46 |
| fungi | and to use the implicit version from the env name | 18:46 |
| mnaser | i see a bunch of "WARNING zuul.GerritConnection: Unable to get change for <GerritTriggerEvent ref-replicated opendev.org/zuul/zuul-jobs>" and "WARNING zuul.GerritConnection: Unable to get change for <GerritTriggerEvent ref-replication-done opendev.org/zuul/zuul>" in my logs, is this expected (in trying to troubleshoot why my merges fail) -- or does opendev see those warnings too? | 18:46 |
| clarkb | mnaser: I think that might be zuuls way of ignoring replication eveents | 18:47 |
| clarkb | possible we could log that better | 18:47 |
| mordred | fungi: in answer to your earlier question about what python people are likely to have vs custom compiled - I'm starting to think the correct answer is "both" - even though that explodes the matrix even more | 18:47 |
| mnaser | probably no need to log it as a warning i assume | 18:47 |
| fungi | mordred: i've always felt "both" when possible is correct | 18:48 |
| clarkb | I'll try to remember to writr an email about this by monday ish | 18:48 |
| mnaser | now whats interesting is it looks like 3 merges are issued by zuul, and one of the 3 is failing | 18:48 |
| mnaser | https://www.irccloud.com/pastebin/dFyao4se/ | 18:49 |
| mnaser | "commit: None" | 18:49 |
| mnaser | mordred: nice, tox-py38 has officially failed! | 18:54 |
| mordred | mnaser: woot! | 19:00 |
| mordred | mnaser: I guess I should fix that in that patch | 19:00 |
| mnaser | mordred: if you end up doing that, mind adding https://review.opendev.org/726552 as a dependency too? so that we can see our ci pass too :> | 19:02 |
| openstackgerrit | Monty Taylor proposed zuul/zuul-jobs master: Set ignore_basepython_conflict to true https://review.opendev.org/726555 | 19:03 |
| openstackgerrit | Monty Taylor proposed zuul/zuul-jobs master: pyenv: install libffi-dev https://review.opendev.org/726552 | 19:03 |
| openstackgerrit | Monty Taylor proposed zuul/zuul-jobs master: Set ignore_basepython_conflict to true https://review.opendev.org/726555 | 19:03 |
| mordred | mnaser: done! | 19:03 |
| mordred | clarkb, fungi: got a sec to review https://review.opendev.org/#/c/726552 ? | 19:04 |
| mnaser | mordred: awesome. ok, so once this is done, we should be reporting and passing. and then i'll recheck that revert of revert of revert of revert for the venv | 19:04 |
| mordred | mnaser: \o/ | 19:04 |
| mordred | mnaser: that's very exciting | 19:04 |
| mnaser | yeah i thought this was gonna be a bit more of a pain but noonedeadpunk pretty much setup 99% of the work | 19:05 |
| mnaser | mordred: i wonder if it would make sense for us to move the config repo for that tenant into opendev | 19:05 |
| mnaser | so folks can add jobs that we can run too.. | 19:05 |
| mnaser | easier to add someone as a reviewer on a gerrit change than ping someone :P | 19:06 |
| openstackgerrit | Monty Taylor proposed zuul/zuul-jobs master: Add new non-npm specific javascript jobs https://review.opendev.org/726547 | 19:06 |
| mnaser | mordred: btw i think you left a +2 on PS#2 on https://review.opendev.org/#/c/726552/3 | 19:07 |
| mordred | mnaser: that's because I'm dumb | 19:08 |
| mnaser | :P | 19:08 |
| mnaser | mordred: left a small comment on the html.escape cahnge | 19:10 |
| mnaser | it also looks like cgi.escape and html.escape don't behave the same too | 19:11 |
| mnaser | oop | 19:11 |
| mnaser | mordred: just went through the painful diffing and left a comment at where it failed too | 19:16 |
| mordred | mnaser: ugh | 19:17 |
| *** Goneri has joined #zuul | 19:17 | |
| openstackgerrit | Monty Taylor proposed zuul/zuul-jobs master: Set ignore_basepython_conflict to true https://review.opendev.org/726555 | 19:18 |
| openstackgerrit | Monty Taylor proposed zuul/zuul-jobs master: Set ignore_basepython_conflict to true https://review.opendev.org/726555 | 19:19 |
| mordred | mnaser: thanks! | 19:19 |
| mnaser | np :) | 19:19 |
| * mnaser keeps telling themselves "just close this rabbithole to go do something else" and we keep going deeper | 19:19 | |
| mnaser | :P | 19:19 |
| mnaser | i think this might be it though | 19:19 |
| openstackgerrit | Monty Taylor proposed zuul/zuul-jobs master: Add new non-npm specific javascript jobs https://review.opendev.org/726547 | 19:24 |
| openstackgerrit | Monty Taylor proposed zuul/zuul-jobs master: Get rid of use of include: with static: https://review.opendev.org/726556 | 19:26 |
| mordred | mnaser: infinite rabbit holes seem to be my speciality these last few weeks | 19:27 |
| mnaser | mordred: wait, our change is even more questionable now we have two sets of outputs? | 19:27 |
| mnaser | if its <py3, the tests would have a differeent refernce than >py3 | 19:28 |
| openstackgerrit | Merged zuul/zuul-jobs master: pyenv: install libffi-dev https://review.opendev.org/726552 | 19:35 |
| mordred | mnaser: oh god | 19:36 |
| mordred | mnaser: I have an idea | 19:37 |
| openstackgerrit | Monty Taylor proposed zuul/zuul-jobs master: Set ignore_basepython_conflict to true https://review.opendev.org/726555 | 19:41 |
| mordred | mnaser: I had a different idea, but decided just sledgehammer | 19:41 |
| mnaser | mordred: fingers crossed | 19:42 |
| mordred | typo | 19:43 |
| openstackgerrit | Monty Taylor proposed zuul/zuul-jobs master: Set ignore_basepython_conflict to true https://review.opendev.org/726555 | 19:57 |
| openstackgerrit | Mohammed Naser proposed zuul/zuul-jobs master: Set ignore_basepython_conflict to true https://review.opendev.org/726555 | 20:43 |
| mnaser | AJaeger: https://review.opendev.org/#/c/726555/8 should be ready to land to fix 3.8 issues (and making vexxhost ci passing by default) | 20:51 |
| *** avass has quit IRC | 21:03 | |
| *** Goneri has quit IRC | 21:07 | |
| *** Goneri has joined #zuul | 21:13 | |
| *** tumble has quit IRC | 21:15 | |
| fungi | if you can build a ledge in the rabbit hole, then you can probably set up a bivouac there and make camp | 21:22 |
| *** Goneri has quit IRC | 21:24 | |
| fungi | at least then you can continue your descent another dat | 21:24 |
| fungi | day | 21:25 |
| openstackgerrit | Merged zuul/zuul-jobs master: Set ignore_basepython_conflict to true https://review.opendev.org/726555 | 21:32 |
| mnaser | fungi: aha. well, thanks for that +w. that makes our ci passing now and doing 3pci :) | 21:33 |
| fungi | thanks for the actual fix for our broken jobs! ;) | 21:59 |
| mordred | fungi, mnaser: fascinating failure on mnaser's 3pci on https://review.opendev.org/#/c/726413/ | 22:10 |
| mordred | ianw, mnaser: ^^ I know what the issue is | 22:26 |
| mordred | we're assuming that you want to use the distro-installed python3 | 22:26 |
| mordred | but - in mnaser's case, python is coming pyenv and is in /usr/local/bin/python3 | 22:26 |
| mordred | so the correct behavior for these roles would be to use _that_ python to make the tox venv | 22:27 |
| mordred | I think if we want to do this properly, we need to have ensure-python set a cacheable fact that contains the python path | 22:27 |
| mordred | then in ensure-pip we use that, defaulting to python3 if it's not set, to find python3 -m venv | 22:28 |
| mordred | then in ensure-tox we also use that, defaultig to /usr/bin/python3 | 22:28 |
| mordred | it might be _easier_ to just remove /usr/bin from it and use python3 for the test | 22:28 |
| clarkb | shouldnt that just be in the path already? | 22:28 |
| mordred | since /usr/local/bin is usually in the path before /usr/bin/ and if it has been installed is probably what is desired | 22:28 |
| mordred | yeah | 22:28 |
| mordred | so - I'm going to try just removig the explicit /usr/bin | 22:29 |
| clarkb | ++ | 22:29 |
| openstackgerrit | Monty Taylor proposed zuul/zuul-jobs master: Revert "Revert "ensure-tox: use venv to install"" https://review.opendev.org/726413 | 22:30 |
| mordred | clarkb: let's see if that passes on vexxhost | 22:30 |
| openstackgerrit | Monty Taylor proposed zuul/zuul-jobs master: Add new non-npm specific javascript jobs https://review.opendev.org/726547 | 22:44 |
| veecue | is there anything special I have to consider when importing zuul/zuul-jobs? The jobs get imported properly and are listed in zuul-web, but are silently ignored when executing | 22:45 |
| mnaser | veecue: does your base job include them too? | 23:20 |
| veecue | I think, I've found it. They implicitly use the job called "base" as the base-job, which I hadn't defined. But is there any way to make builds with invalid jobs fail instead of silently ignoring them? | 23:22 |
| mnaser | veecue: generally, i think the web ui will show a little notification bell in the top right corner | 23:24 |
| mnaser | which will say what are the current config issues | 23:24 |
| ianw | mordred: you need the /usr/bin beacuse of the way pip: module works ... | 23:25 |
| veecue | mnaser: It does, but only for unexisting jobs, etc. Also, when I add an unexisting job to the a pipeline, I would expect it to fail | 23:25 |
| ianw | iirc it has something like if startswith("/") exec it, otherwise use like shell wrapper | 23:26 |
| ianw | https://github.com/ansible/ansible/blob/devel/lib/ansible/modules/packaging/language/pip.py#L476 is what i'm thinking of and that get_bin_path function | 23:28 |
| *** tosky has quit IRC | 23:38 | |
| mordred | ianw: oh ... ugh :( | 23:55 |
| mordred | ianw: wait - wouldn't that still work though? | 23:55 |
| mordred | ianw: (the answer is a very red no apparently) | 23:56 |
| openstackgerrit | Monty Taylor proposed zuul/zuul-jobs master: Revert "Revert "ensure-tox: use venv to install"" https://review.opendev.org/726413 | 23:59 |
| mordred | ianw: well - we have vexxhost 3pci reporting now - so we should be able to eventually figure it out | 23:59 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!