1

My team has multiple low level and high level packages written in Python and they are dependent on each other, we typically install them as GitHub repositories using pip. Basically, I would like to automate the process of providing versions to the libraries, so the production code is easier to manage and rollback to previous versions in case of emergency.

Right now, we use a version string in the code and git tags to annotate the releases. By using commitizen's cz bump --changelog we can manually update the versions in the file and when PR is approved and merged (due to main branch protection rules), the tag can be pushed too.

I've been trying to find a way to automate the process and I've encountered multiple problems along the way.

  1. The commitizen-action is almost perfect. But, since we have main branch protection in place, a PAT and dedicated user to bypass the rules are needed. Since I'm not an admin of our organisation, adding the tokens to every repository and rotation of tokens aren't very efficient. Is there a way to circumvent that so we, as a team, can manage our repositories?
  2. I tried to write a custom GitHub Action executing cz bump --changelog when a pull request is created, so everything is still being done on the current feature branch. But then some commits after a PR review still can be pushed to the branch and the tag will point to the previous version of the code. I couldn't find a way to execute an Action just before merging the branch into main which theoretically would be something I need.
  3. Maybe I am missing something? Is there a way to automatically and efficiently version Python packages and release them? We also use CircleCi, but I guess we still need the tokens to push to main. We've been thinking about our private package storage, are there any tools like that e.g. on Azure?

Edit: I'm also open to different approaches to versioning our releases and deployment approaches.

pdaawr
  • 436
  • 7
  • 16

1 Answers1

1

Been fighting the same thing and the short answer is I haven't gotten to a good solution as the whole having to issue a PAT just to push to a protected branch is a bit sketchy. I think our approach in the short term will be to put together a terraform/ansible job that will regenerate the PAT and replace it at some interval so that at least if the PAT gets out we limit the duration of damage that can be done.

If you are working on an Enterprise instance you could have your "team" moved into an organization under your companies Enterprise. This would allow you to have secrets at the organization level which can be shared with all the required repositories.

The other way I have been starting to explore this is to make it so my version bumping happens one a PR is kicked off. That way anything I need to push isn't being pushed to a protected branch and the update is still available and NOT user controlled. I wish I had a better answer for you and I will be watching this closely to see if anyone has anything different. You can also by the way create a GitHub App which can bypass branch protection but that seems like a lot of work for something that other SCM system provide.

Some background reading material that helped me get to where I am right now:

badrobit
  • 743
  • 1
  • 11
  • 25