Push to protected branch

#1

I have protected the develop branch of our GitHub repo. We require pull requests and a bitrise build before merging.
However, I also have a workflow step that increments and commits a new build number. The build fails when trying to push the commit because the branch is protected. Has anyone figured out a way to get around this?

1 Like

#2

Hi @ryanwalker,

Thanks for asking this here! :slight_smile:

Well, if a branch is protected then it means that it’s impossible to push to that branch.

There’s one option, but I wouldn’t advise to utilize that unless you really have to: on GitHub if you open the protected branch’s settings there’s an option:

Include administrators - Enforce all configured restrictions for administrators.

If you disable this option then admin accounts can push to that branch. If you really want to use this option I’d suggest you to create a “CI” github user and add that user directly to that repo, and register the SSH key for that user, that way it’s possible to push to a protected branch.

But in general you should never push to a protected branch. Bumping a version number should happen through a PR too. In addition to that, it might also be a good idea to not to manage the version number manually (bumped through a PR) and use the build number from Bitrise.io, instead of storing it in the repo. This has the advantage that you can quickly find the build which generated that specific artifact as well.

I shared more about this approach at https://stackoverflow.com/questions/33821137/build-versioning-in-continuous-delivery/33821876#33821876


Copy of the answer from stackoverflow:

In general you should have:

  1. A manually managed version number.
  2. Any number of “reference” numbers.

The first point is crucial if you care about semver or in case you have to provide compatibility information for other tools/libs. It’s only you who can tell whether a new “release” breaks anything - the most popular indication system is following the semver versioning rules.

The second point (“reference” number) might or might not be important for you. You usually don’t need more than one, the CI/CD build’s version number (every popular CI/CD service has a build version number ID which refers to that specific “build”). The point of this number is that you can quickly check the related CI/CD build/logs of an artifact if you need it.

How to merge the two (or more) parts?

It’s not uncommon to have separate “version” and “build” numbers. In fact every iOS project have that by default. In that case you have the “version” number managed manually, and a separate “build” number managed automatically. The build number can be in the artifact’s name, or can be printed when someone retrieves the --version information in case of a binary (ex: $ brew info -> 0.9.5 (git revision 18c48; last commit 2015-11-02)

Alternatively you can either add new components to semver (x.x.x.BUILDNUM), use the last component of semver (x.x.BUILDNUM - I wouldn’t recommend this if you have a strictly incremental BUILDNUM) or simply include the “build” number in the name of the artifact.

These are all possibilities, you’ll have to pick the best one for your case. You have to define the meaning of these numbers and decide where the number should be presented (e.g. should it be part of a --version call or should it be just part of the filename).

edit: to reflect on your question about “should CI server increment the build version and create a tag in VCS?” - I would never recommend this. A CI server can have issues too, you should never modify your code from a CI process. Accidentally overwriting (e.g. force pushing) something can be really dangerous. That’s why it’s better to just use the Build Number exposed by the CI/CD service.

0 Likes

#3

Hi Viktor,

I know it’s an old thread, but I’m running into an issue …

Before reading your post I had my deploy workflow bumping the version of our project, tagging VCS, and pushing the new commit (using [skip ci] to avoid another build). But as I updated master to be a protected branch, I ran into issues, and plus, I would rather not have the deploy workflow incrementing the version for each deploy in case I want to deploy multiple times from master for different environments and keep the version consistent for each release.

After reading your post, I took your suggestion and changed my PR workflow to be the workflow that bumps the version. So I made a PR, it kicked off our “build” workflow, which would bump the version as part of the workflow (amend commit the previous commit with the new version and [skip ci] added), and push the changes. It entered into an endless cycle as the [skip ci] had no impact. I then read your post here, and the docs here, and understood that skipping PRs depend on the title including the [skip ci], not the commit itself.

But changing the PR title is not something that can be done in the workflow (unless I hook into the GitHub API), because the moment [skip ci] is added, I’ve disabled the ability to auto kickoff a bitrise build by pushing any potential changes needed for that said PR. Is adding [skip ci] in the PR title only for the purpose of developers wanting to make PRs that don’t kick off a build cycle? Or is it meant to be used in some way by the workflows of the CI?

By the way, our project is a react native project, which is using npm version to increment the package.json, which has a postversion script to run a react native package (react-native-version) which updates the iOS and Android versions and build numbers to keep everything aligned. This is all happening currently in the bitrise workflow.

What would you suggest here? You wrote in another post that normally you would keep the incrementing of version numbers separate from the CI process and have it as part of any other change in the code base, but I’m wondering if there is a best practice for bumping versions within PR workflows and pushing the changes?

Thanks you so much!

0 Likes