Check that main branch is up to date with remote

[leplatrem]

I accidentally published a release from a main branch that was not up to date with remote.

The error was only visible at the post release step, because push failed obviously.

Maybe it could help to check that local is up-to-date (and does not diverge) right before the release step?

[mauritsvanrees]

Could help. But I immediately think of questions then.

• Should we do this before release or before release? Preferably the first. But if someone only calls release, then you do want to check it.
• Such code should work with git, mercurial, bazaar and subversion.
• Do we make this a new question? "Shall we update the local branch from the remote? [Y/n]?"
• Do we git pull the changes and apply them?
• Or do we git fetch and only detect changes? Do we then offer to merge them, or do we quit with an error?
• If there are changes, then the user should view them before going on with the release. Do we show the changes or do we quit so the user can inspect?
• What if the user has made local changes (fixed a typo in the readme). Does that give a false positive for the local not being up to date?

So a lot of questions, although that does not mean we should not do this.

On the other hand: when pushing fails, you can fix it up, and then make a new release.

BTW, this could be done in an extension. See the entrypoints documentation. Register an extension for the zest.releaser.prereleaser.before (or maybe the zest.releaser.releaser.before) entry point and maybe start simply by doing a git pull there.

[leplatrem]

Should we do this before release or before release?

🤔 I would say right before release. My workflow is usually the following:

• prerelease and open a pull-request
• gets approved and merged (can be days)
• git co master && git pull (<-- this is where I forgot that the branch is now called main)
• release && postrelease (<-- this is where a busted version was published on pypi and I realized it in postrelease)

Do we make this a new question? "Shall we update the local branch from the remote? [Y/n]?" Do we git pull the changes and apply them? Or do we git fetch and only detect changes? Do we then offer to merge them, or do we quit with an error?

Detecting that the local branch is behind is already something. I don't think we should try to automate anything at this point. Error and exit.

What if the user has made local changes (fixed a typo in the readme). Does that give a false positive for the local not being up to date?

I don't think we should introspect too much, just that local is behind remote and not the opposite. Something like git remote update && git status -uno maybe? (don't know about other SVCs)

Thanks for pointing out the extension part!

[mauritsvanrees]

My workflow is simply to do fullrelease. There the only reasonable moment to do this check, is before the prerelease phase. So our workflows may differ too much for this to be usefully added to zest.releaser.

Well, technically we could do it before prerelease, then add a marker in the data dictionary that we keep, and then before release check if the marker is there. If so, then we do nothing. If not, then we do the check.

I don't plan on working on this currently. We could consider a pull request. But maybe easiest and better to do this in an extension. That also means you need not worry about mercurial and others.

[leplatrem]

Thanks for your feedback, and for the tool of course! I assume we can close then.