Deployment best practices?

Deployment
1

Hello everyone!

I’d like to get some advice for a travis build that I’m working on.

I’m compiling a Python script I wrote using PyInstaller across OS’s (windows, osx, and linux). The build works and is ready for release.

However, I’m trying to think through the deployment stage of my code. At current, deployment stage is set to start on the ‘master’ branch, but realize that the deploy script will run each time the PR is updated with new commits.

The deploy script consists of deploying the binaries to Github as a draft release. But it’s annoying to have to delete draft after draft.

I’ve thought about doing the deployment after I tag the commit, which I could do after code review. Ideally, I’d like to push deployments after PRs are approved, and after merge.

What is the best way to accomplish this?

Quick edit: I’m also experiencing the “double builds” issue, which I think is related to the above question. Restricting the PR request build would prevent the PR from showing the status of the build on the PR, though you could see this in the list of commits but seems like a work around. If there is a best practice around this, that would also be appreciated.

2

As per https://help.github.com/en/github/administering-a-repository/about-releases, a Github release must be associated with a Git tag. This is their design/limitation (depending on how you look at it), so Travis cannot do anything about that.

So you either create tags manually, or create one automatically during a Travis build. See https://docs.travis-ci.com/user/deployment/releases/ for details.

Yes, if you wish to create a “nightly” release each time you push to master, this means you’ll need to create a tag for that and move it each time (and use overwrite: true to overwrite an existing release). See https://github.community/t5/How-to-use-Git-and-GitHub/Nightly-Builds-Latest-Branch-Releases/td-p/4922.

Creating a tag may trigger another build, for the newly-created tag. If it does, your logic needs to somehow recognize this situation (to e.g. avoid infinitely creating new releases).

3

I deploy to PyPI for tags (make sure to do it from only one build job and for the main repo), and also deploy to Test PyPI for commits to master.

This means I’m testing the whole deploy step during the development cycle, not just when actually tagging a release.

For example, see: