So here's the deal: For each of our 50+ repositories, we have a three-tiered branch model: Dev, Test, Master. Dev can be updated whenever the Devs want, and changes are aggregated by a team lead and submitted for deployment to our test environment, at which time the code is merged to the test branch and tagged. Once the code is tested and passed, (and deployed) it is migrated to master. After the code is in master and deployed successfully, we kill the old branches and create new ones only when requested.

But we are scanning our code with SonarQube and Fortify and it's getting overwhelming to update our scan schedule every time a new branch is requested. We want to keep the model of refreshing the branches each release.

My thought is to create one new branch per repository that would always stay the same name but which would automatically have the code from the test branch merged in to it each time a merge to test is done from the dev branch. We would use this branch for code scanning, as it should match the changing branch exactly.

We could kick it off as part of our Jenkins pipeline scripts, but that would just move the problem from 'updating the branches in the scanning schedules' to 'updating 50+ scripts' (or one parameterized list, which is better, but not ideal)

Is there a way to automatically perform a merge from the dev branch to a permanent test branch at the same time as the primary merge to the impermanent primary test branch? All without having to go in and update the scripts by hand (or better, a parameterized list)? Am I likely to run into problems (parent branch issues, etc?)

1 Answers

brian m. carlson On

Typically, the behavior you want here is something server side, and there are a couple ways to do it.

First, if you're using pull requests, you can set the code to be scanned on pull request as part of CI. Code that doesn't pass doesn't merge (or only merges with administrator override). This is the way people traditionally handle this problem, and it works pretty well. You can have a set of global scripts that all your CI jobs use, which will require you to update multiple scripts the first time, but not in subsequent iterations.

Second, if your server-side implementation has support for a post-receive hook, you can add such a hook to update the permanent test branch when the push occurs. This requires a server-side implementation that supports that, and most don't.

Third, if your server-side implementation has support for webhook delivery, you can use that to talk to a service which can perform the action for you. This will require that service to have a token or SSH key of some sort to perform that task.

Fourth, if you're using GitHub (the cloud version, not the self-hosted one), you may be able to opt in to GitHub Actions and use it to perform this task. This will also require some sort of secret which can be used to update the branch.