Tagging beta / rc releases
Greetings, I wanted to raise the topic of maybe using beta / rc tags to publish pre-release versions of zuul / nodepool to pypi. Currently, before each official release we usually select a git SHA to be installed onto zuul.opendev.org, to ensure we can run a scale without any issues. Then a few days later, if things are well we tag a new release or work to address the problem. Then restart the process until things look good. I really like this approach, as currently there is no larger zuul and helps to catch any issues before our users install the released version. However, I would like to propose we make a minor change, is when we select to git SHA, is to also tag it using a pre-release version number (eg: beta / rc). By having it pre-release, (eg: pip install --pre zuul) would allow my current tooling (today we only installed from pypi, not git) to pick up the change and also provide some feedback. Our deployment tooling is setup to only use releases from pypi (wheels) in an effort to try not to carry any patches downstream. We could also switch to pip install via git, however this would add some extra overhead to production servers to compile wheels. - Paul
Paul Belanger <pabelanger@redhat.com> writes:
We try very hard to keep Zuul and Nodepool always releasable. We deploy it continuously in OpenDev, though, as you note, we don't always restart it. I would prefer that we continue to focus on the tool as continually deliverable rather than relying more heavily on releases. Releases are useful checkpoints, good fallbacks if something does go wrong, and a good alternative for folks who do not want to or can not deploy continuously. But all of the Zuul programs are designed to be continously deployed. It's sort of the point. The best way to test an upcoming Zuul release is to test the code from git, or the containers (which are built on each commit). If it would help, we could probably create jobs to publish a wheel on every commit? -Jim
On Tue, Apr 23, 2019 at 07:50:29AM -0700, James E. Blair wrote:
Thanks for info. Per commit wheels would be helpful, I'm assuming that would not be published to pypi, and say tarballs.opendev.org (assuming that is a thing now). That is a minor change on my side, which isn't a large issue. While not running containers yet, I am still installing release versions of zuul / nodepool into their own virtualenvs, so mostly when a new release is uploaded to pypi, we upgrade deployment tooling to that, and a new virtualenv is created with the latest and greatest. I've found this method to be an easy way to downgrade quickly if needed. - Paul
On 2019-04-24 07:26:07 -0700 (-0700), James E. Blair wrote: [...]
Could basically run a twine upload job in the post pipeline, though it might need tweaking to match the filename, but there shouldn't be any tagging required. My local workflow is basically: setup.py bdist_wheel sdist && twine upload dist/* (Granted I do some additional checks in there, but that's the meat of it.) -- Jeremy Stanley
On Wed, Apr 24, 2019 at 02:53:18PM +0000, Jeremy Stanley wrote:
Looking at our current release-zuul-python jobs, and talking with fungi, I am pretty sure we can just add[1] the job to the post pipeline and we'll start publishing tarballs / wheels to pypi our dev versions properly. - Paul [1] https://review.opendev.org/655474/
participants (3)
-
corvus＠inaugust.com
-
Jeremy Stanley
-
Paul Belanger