Make zest.releaser more CI/CD friendly

[Behoston]

I'm trying to automate releases with Github actions. Zest works excellent locally, but on CI it was very hard to set up.

I want to archive one-action release: push tag or click release on github. With current version of zest is possible, but only release step. The problem was with clean checkout. Additional config will be helpful. For example:

[zest.releaser.prerealse]
ignore-dirty-checkout = yes
skip-on-dirty-checkout = yes

and so on. It will be nice to allow force default choices when flag --no-input or skip step when some check fails.

PS I wanted to fix it myself but you are using so-called helpers like zc which totally unhelpful... with python 2.7 it will install libs from python3 (using yield) on python3.7 it hangs on environment setup, so I gave up.

[reinout]

Those helpers you mention are probably the zc.test-something ones? :-) At the time we created zest.releaser, some 10 years ago, they were the standard tools. Likewise doctests. Now I'd rather use pytest or so. And the whole test setup (we need bzr, hg, git, svn, etc for real testing) is also quite brittle, also because sometimes the textual output of those tools changes. Ideally, I'd make a dockerfile to test everything to make it easier to develop on zest.releaser. Such a dockerfile might get a bit creative if I want to include multiple pythons.

Anyway, back to your actual question. Yes, I think an ignore-dirty-checkout would make sense. Assuming the checkout isn't so dirty that we can't do git commit or git tag or git push, that is.

I'm interested in your integration with github actions. I myself have a few projects where colleagues use zest.releaser to make a release. I've configured travis-ci to automatically do a release to pypi (with the correct credentials) when it encounters a tag. Handy, because those colleagues don't need to setup their own pypi accounts.

But how does it work when you use zest.releaser inside github actions? Github actions, to me, sounds like it reacts to commits, it surprises me that it can do further commits on its own.

[Behoston]

TBH I gave up with auto releases form github actions last night, but today I started again just because I got answers on all my questions/issues :) I'm very happy that this repo is still maintained and you are open to changes.

Here you have my PoC with commit from github actions, it is simpler than I though: https://github.com/Behoston/action_tests/blob/master/.github/workflows/ (it's funny because I forgot about recurency and job should create new job after push, but nothing happened)

So it should work with zest releaser and it will be working with release from master. Today I should have working version here: https://github.com/Behoston/hmm_profile it can trigger only on release creation (works bad, triggers 3 time per one release, idk why) or tag push (works ok).

Another option useful idea for CI: when tag checked out, zest should use it as version. For example:

1. I developed new feature. Actual version 0.1.1.dev0
2. git tag 0.2.0
3. zest should use 0.2.0 instead of 0.1.1 as new release version.

For now, I will need to bump version in setup.py then push same tag to trigger release (or hack a little and edit setup.py on CI before release, but it will generate additional commit).

[reinout]

Yes, we still actively maintain it. We actually use it ourselves a lot all the time, so that's quite a motivation :-)

I'll look a bit further at your setup tomorrow morning (I'm off to bed now). One thing to keep in mind: zest.releaser was intended to do everything from "un-devving" the version, making the tag and upping the version number. So when you do your own tagging, you might be working "against" zest.releaser. It might still work, but it is something to pay attention to.

And... perhaps zest.releaser needs some changes to work in a github actions (or gitlab's) world.

[Behoston]

https://github.com/Behoston/hmm_profile/runs/458955650 Finally, :smiley: it works quite good. It requires:

• copy tests from test workflow to ensure that all tests passing (maybe it's possible to check/wait via API if test pass on test workflow) and remember to update both workflows
• change version in setup.py to x.y.z.dev0
• tag x.y.z
• not touching master branch till release action

[reinout]

Something I noticed when looking at your github actions output: https://github.com/Behoston/hmm_profile/runs/458979096?check_suite_focus=true#step:7:179

This was one of the things I feared a bit. You're making a tag to start the release process. The actual releasing is done by zest.releaser, which tries to make the same tag. This fails as the tag already exists.

The only difference between the two tags is the release date in the changelog, so it doesn't make much difference.

What I'm used to is something like this: https://github.com/nens/threedi-scenario-downloader/blob/master/.travis.yml#L15-L23 That's for travis-ci.com, but the same idea applies to github actions. The one doing the release has to have zest.releaser installed locally. You run "fullrelease" locally, which also creates the tag. Travis (or github actions) picks up the tag, just like you do now, and only has to upload to pypi. In that project, I configured zest.releaser not to upload anything (as travis does it): https://github.com/nens/threedi-scenario-downloader/blob/master/setup.cfg#L4-L6

Running zest.releaser locally would save you two actions:

• Changing the version in setup.py.
• Making the (slightly incorrect) tag by hand.

Drawback: anyone doing a release has to have zest.releaser installed locally. To work around that, a manual github action, only available on master after successful tests, that fires off zest.releaser would be great... I have two project in which that would save me some work twice a month :-)

[reinout]

Just to make sure: it sounds like you don't need an ignore-dirty-checkout = yes-like option anymore?

[Behoston]

Problem with tag should be fixed by git fetch --tags because only master is pulled. I don't need ignore dirty checkout flag for now, if only all releases from master branch it's ok. I do not plan to release from other moments of git history or I can do it manually if needed.

But still, in my opinion more flags will be great.

[reinout]

Well, as someone who's maintained this piece of software for 10 years: less options are great :-) So if something isn't absolutely needed, I try not to add it. I'm closing this issue for now, ok?