| *** fzzf2 is now known as fzzf | 03:05 | |
| fzzf | hello all, After setting up the external CI, how to use opendev/ci-sandbox to test the external CI? | 03:15 |
|---|---|---|
| *** ykarel|away is now known as ykarel | 04:44 | |
| *** ysandeep|out is now known as ysandeep | 06:28 | |
| opendevreview | daniel.pawlik proposed openstack/project-config master: Add project openstack/ci-log-processing https://review.opendev.org/c/openstack/project-config/+/815260 | 07:01 |
| *** jpena|off is now known as jpena | 07:31 | |
| *** ykarel is now known as ykarel|lunch | 08:55 | |
| *** ysandeep is now known as ysandeep|lunch | 09:44 | |
| *** ysandeep|lunch is now known as ysandeep | 10:33 | |
| *** rlandy is now known as rlandy|ruck | 10:34 | |
| *** jcapitao is now known as jcapitao_lunch | 10:40 | |
| *** ykarel|lunch is now known as ykarel | 10:56 | |
| *** dviroel|rover|out is now known as dviroel|rover | 11:11 | |
| *** jpena is now known as jpena|lunch | 11:24 | |
| *** tosky_ is now known as tosky | 11:25 | |
| *** ysandeep is now known as ysandeep|brb | 12:03 | |
| *** jcapitao_lunch is now known as jcapitao | 12:04 | |
| *** jpena|lunch is now known as jpena | 12:25 | |
| *** ysandeep|brb is now known as ysandeep | 12:25 | |
| *** Guest3656 is now known as redrobot | 13:03 | |
| opendevreview | Hervé Beraud proposed openstack/project-config master: Allow to check release approval for DPL teams https://review.opendev.org/c/openstack/project-config/+/815497 | 13:08 |
| opendevreview | Hervé Beraud proposed openstack/project-config master: Allow to check release approval for DPL teams https://review.opendev.org/c/openstack/project-config/+/815497 | 13:09 |
| *** rlandy|ruck is now known as rlandy|ruck|mtg | 13:16 | |
| *** lbragstad6 is now known as lbragstad | 13:28 | |
| *** sshnaidm_ is now known as sshnaidm | 14:03 | |
| clarkb | fzzf: you can push changes to the ci-sandbox repo and then check that your CI system triggers against them as expected | 14:39 |
| opendevreview | Merged openstack/project-config master: Add project openstack/ci-log-processing https://review.opendev.org/c/openstack/project-config/+/815260 | 14:55 |
| *** ysandeep is now known as ysandeep|out | 15:08 | |
| *** ykarel is now known as ykarel|away | 15:16 | |
| *** jpena is now known as jpena|off | 16:33 | |
| *** rlandy|ruck|mtg is now known as rlandy|ruck | 17:33 | |
| opendevreview | Clark Boylan proposed openstack/pbr master: Add a PEP517 interface https://review.opendev.org/c/openstack/pbr/+/797898 | 17:34 |
| clarkb | fungi: stephenfin ^ fyi that just does a super minimal update. I haven't even begun to think about testing. But fungi found over the weekend that not using pyproject.toml is starting to emit deprecation warnings so getting to a point where we can at least minimally keep up with what pypa wants seems like a good idea | 17:35 |
| clarkb | re testing, I'm not even quite sure I know how to do it. I guess we would need to create a mocked up package in pbr's tests (I think it alreadydoes this) with no setup.py and rely on $pypatool to load pbr which loads setuptools directly/ | 17:36 |
| fungi | we could test by turning on deprecation warnings as errors | 17:39 |
| opendevreview | Yuriy Shyyan proposed openstack/project-config master: Reinstating InMotion cloud https://review.opendev.org/c/openstack/project-config/+/815532 | 17:56 |
| opendevreview | Clark Boylan proposed openstack/pbr master: Test pep517 support https://review.opendev.org/c/openstack/pbr/+/815534 | 17:57 |
| clarkb | I'll admit I'm a bit afraid of running ^ locally so I haven't :) | 17:58 |
| clarkb | I need a better isolated test env | 17:58 |
| fungi | clarkb: 815532 should reenable inmotion-iad3 in nodepool | 18:02 |
| clarkb | cool you alredy hcecked the mirror was up and happy | 18:04 |
| fungi | yup | 18:04 |
| clarkb | approved lets see how it does | 18:04 |
| opendevreview | Merged openstack/project-config master: Reinstating InMotion cloud https://review.opendev.org/c/openstack/project-config/+/815532 | 18:18 |
| clarkb | hey I got it to fail successfully at least | 18:25 |
| clarkb | couldn't find pbr.build | 18:25 |
| clarkb | if I manually create venv and install the checkout of pbr to that I can import pbr.build | 18:27 |
| clarkb | but in the test it is done that and failed to find pbr.build? weird. Also I notice it thinks the version is 0.0 possibly related | 18:27 |
| clarkb | like maybe pip is installing pbr-latest because what I'ev preinstalled is version 0.0 | 18:28 |
| clarkb | but pbr-latest is without pbr.build | 18:28 |
| opendevreview | Clark Boylan proposed openstack/pbr master: Test pep517 support https://review.opendev.org/c/openstack/pbr/+/815534 | 18:39 |
| clarkb | lets see if adding -v to the pip invocations might give us better hints to why these unexpected behaviors are happening | 18:39 |
| clarkb | Successfully installed pbr-5.6.0 <- it does seem to be overriding my local pbr-0.0 install. Time to figure that out | 18:53 |
| clarkb | fungi: can the #egg=pbr suffix on a file:///foo/bar/openstack/pbr#egg=pbr installation specification affect that? | 18:54 |
| opendevreview | Clark Boylan proposed openstack/pbr master: Test pep517 support https://review.opendev.org/c/openstack/pbr/+/815534 | 18:57 |
| fungi | potentially, i think the egg parameter for setting the package name is no longer relevant? | 18:58 |
| clarkb | I'm actually wondering now if that causes pip's vcs support to kick in and the latest patchset drops it to just be a path so pbr can do it itself | 18:59 |
| clarkb | but thats half guess | 18:59 |
| clarkb | it also isn't clear to me if pyproject.toml will always download the latest version of a tool if you don't specify a version. But one thing at a time | 19:00 |
| clarkb | good news is the test does seem to do what we want it to, just with the wrong result :) | 19:00 |
| fungi | yeah, i suspect it will always try to fetch the tool from somewhere, so we may need to preinstall pbr and make sure the version for it sorts newer than whatever's on pypi? | 19:03 |
| clarkb | that is what the test does. It preinstalls pbr using the loacl zuul checkout but for some reason it installs that as pbr-0.0. Then when pip runs to install the pyproject.toml'd project it installs pbr-5.6.0 removing support for the build | 19:04 |
| clarkb | I'm hoping that if I can install pbr-5.6.1-devXY then it won't overwrite my preinstalled pbr in the test | 19:04 |
| clarkb | fungi: stephenfin: ok I think what is happening is when we install pbr into the venv it is using the new pyproject.toml stuff and that is broken and setting the version wrong | 19:21 |
| clarkb | https://zuul.opendev.org/t/openstack/build/6f6ece94c5b54168b970b5db32c62d08/log/job-output.txt#1089-1092 | 19:22 |
| clarkb | yay for testing :0 | 19:22 |
| clarkb | er :) | 19:22 |
| opendevreview | Clark Boylan proposed openstack/pbr master: Test pep517 support https://review.opendev.org/c/openstack/pbr/+/815534 | 19:29 |
| clarkb | hrm using setup.py it is still doing a version 0.0 | 19:51 |
| clarkb | I'm very confused about that and cannot reproduce it doing a pip install locally | 19:51 |
| opendevreview | Jeremy Stanley proposed openstack/project-config master: Replace old Xena cycle signing key with Yoga https://review.opendev.org/c/openstack/project-config/+/815548 | 19:53 |
| clarkb | fungi: https://zuul.opendev.org/t/openstack/build/1d0e09d9948b4437ada78320433da201/log/job-output.txt#1094 if you get a chance to look at that and see if anything jumps out to you for why pbr is selecting version 0.0 for itself that would be great | 19:53 |
| clarkb | also I've WIP'd https://review.opendev.org/c/openstack/pbr/+/797898/ to repvent it from merging early | 19:56 |
| fungi | clarkb: that would normally only happen if pbr can't find the .git tree when building, so maybe it's a problem with the tracked files getting copied from the workspace to a temporary (not in-place) build directory but not the .git directory along with them? | 20:13 |
| fungi | may need to see if there's a way to tell pip to do in-place builds | 20:13 |
| fungi | i'm betting it's the /tmp/tmptyy7yavn/tmp6gykh9xe directory mentioned on the line before | 20:15 |
| opendevreview | Yuriy Shyyan proposed openstack/project-config master: Increasing max servers https://review.opendev.org/c/openstack/project-config/+/815552 | 20:18 |
| clarkb | fungi: ya that might be it | 20:21 |
| clarkb | fungi: I put an assert Falase before the stuff that scares me and can run it locally now | 20:21 |
| fungi | i can probably look closer once i get done making dinner | 20:23 |
| clarkb | the tests set PBR_VERSION | 20:31 |
| opendevreview | Clark Boylan proposed openstack/pbr master: Test pep517 support https://review.opendev.org/c/openstack/pbr/+/815534 | 20:41 |
| clarkb | that should set the version properly I hope | 20:41 |
| *** dviroel|rover is now known as dviroel|rover|afk | 20:42 | |
| clarkb | version is set properly but still failing the test beacuse it seems to install pbr-5.6.0 downgrading anyway | 21:02 |
| clarkb | I wonder if that is a behavior of the build dependencies here. It iwll always grab the latest from pypi? | 21:03 |
| clarkb | Not sure I like that since I've got a local version installed | 21:03 |
| clarkb | ah yup it passes --ignore-installed to pip for those rip | 21:03 |
| clarkb | I suspect that we're going to need to determine if that is intentional by pip and why. If intentional it makes it really difficult to test this works | 21:06 |
| clarkb | maybe we try build? | 21:07 |
| opendevreview | Clark Boylan proposed openstack/pbr master: Test pep517 support https://review.opendev.org/c/openstack/pbr/+/815534 | 21:12 |
| fungi | i successfully use build with pbr in a personal project | 21:28 |
| fungi | that was where i noticed the new deprecation warnings from setuptools | 21:28 |
| clarkb | fungi: adding build to the venv beraks pbr installation | 21:46 |
| clarkb | WARNING: Built wheel for pbr is invalid: Wheel has unexpected file name: expected '0.0', got '5.6.1.dev4' <- will pip use build to build the wheels? | 21:46 |
| clarkb | I don't understand how this could break otherwise | 21:46 |
| clarkb | oh even neater py37 does this but py38 does not | 21:50 |
| clarkb | py38 actually gets to run the build of the fake pyproject.toml project but it also fails because pbr.build isn't there | 21:50 |
| clarkb | I strongly suspect that there is a chicken and egg problem here that pip/build didn't really anticipate to be a problem for people | 21:50 |
| clarkb | but we can't test with PBR because their tools eplicitly install PBR from pypi overriding our local changes :( | 21:51 |
| opendevreview | Clark Boylan proposed openstack/pbr master: Test pep517 support https://review.opendev.org/c/openstack/pbr/+/815534 | 21:51 |
| clarkb | thats my last attempt (and ignoring py37 for now) | 21:52 |
| opendevreview | Merged openstack/project-config master: Increasing max servers https://review.opendev.org/c/openstack/project-config/+/815552 | 21:55 |
| fungi | ahh, yeah at the moment i'm using build+pbr with python 3.10.0 | 21:55 |
| fungi | to build my wheels and sdists | 21:55 |
| fungi | however i'm not trying to use unreleased pvr | 21:55 |
| fungi | pbr | 21:55 |
| clarkb | right the issue is that I want to go through the pbr codepaths that the new change adds and everything keeps grabbing a different release which is super annoying | 22:02 |
| clarkb | good news! the thing that py37 tripped over just caused py38 to fail | 22:10 |
| clarkb | but py37 and py36 and py27 passed with my change to build without isolation | 22:11 |
| clarkb | I think at this point we can squash the two chagnes together and figure out why that seems to race | 22:11 |
| fungi | by "fail" you mean there's a traceback? | 22:12 |
| clarkb | fungi: the test system gives a traceback but all we get from pip is that warning (WARNING: Built wheel for pbr is invalid: Wheel has unexpected file name: expected '0.0', got '5.6.1.dev4') | 22:15 |
| clarkb | fungi: https://zuul.opendev.org/t/openstack/build/cabffa721c5e4dcb936c6ce9e6b84039/log/job-output.txt#2053 | 22:16 |
| clarkb | fungi: I suspect this is a flaw in PBRs test framework not properly overriding the PBR_VERSION stuff | 22:17 |
| fungi | likely, yeah | 22:17 |
| fungi | or previously relying on pip/setuptools to be more naive | 22:18 |
| opendevreview | Clark Boylan proposed openstack/pbr master: Test pep517 support https://review.opendev.org/c/openstack/pbr/+/815534 | 22:18 |
| clarkb | that is hopefully the last iteration of the test change before we squash it into the parent | 22:18 |
| opendevreview | Clark Boylan proposed openstack/pbr master: Run python3.9 test jobs https://review.opendev.org/c/openstack/pbr/+/815563 | 22:23 |
| clarkb | fungi: ^ that fixes an issue that I noticed when doing this testing with pbr | 22:23 |
| clarkb | it doesn't run a correct set of jobs. py38 is non voting and py39 isn't run at all. We should run all of them and not worry about the openstack templates whcih are release specific since pbr is not release specific | 22:23 |
| fungi | yep | 22:24 |
| fungi | also worth bringing up with the tc | 22:24 |
| fungi | i expect there are a number of cycle-independent deliverables which have similar needs | 22:25 |
| fungi | the tested runtimes set is more relevant to cycle-based deliverables | 22:26 |
| fungi | for cycle-independent deliverables it's a proper subset in many cases | 22:26 |
| opendevreview | Clark Boylan proposed openstack/pbr master: Test pep517 support https://review.opendev.org/c/openstack/pbr/+/815534 | 22:43 |
| clarkb | I lied ^ is hopefully the last one ebfore I squash. What I realized was getting the pbr version correct isn't actually important as long as we get the tool (build in this case) to ignore the version and use the preinstalled pbr | 22:44 |
| clarkb | While it would be good to figure out why you can't override PBR_VERSION in the test suite I'm having a hard time reproducing it without the full test suite run so it is likely to be a pain to debug. I've just gone back to doing the 0.0 version and will let build use that whihc should work | 22:44 |
| clarkb | if that does work I'll squash the changes and we can reviwe this for real. One thing we might want to consider is that maybe pbr shouldn't dogfood the pyproject.toml stuff to start in whihc case we need to rm the contents added by that change. The reason for this is if we get it wrong we'll be doing pbr releases and hoping whereas for another projects we can simply remove the | 22:45 |
| clarkb | pyproject.toml | 22:45 |
| opendevreview | Clark Boylan proposed openstack/pbr master: Add a PEP517 interface https://review.opendev.org/c/openstack/pbr/+/797898 | 23:04 |
| clarkb | all squashed. I think that is landable now though we might want to add more docs/release notes and possibly drop the pyproject.toml in pbr itself | 23:07 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!