从 CI/CD 提交到存储库

Question

I've recently configured one of my repositories to automatically deploy a release whenever I push a git tag matching "vX.YZ" , but this process isn't entirely automatic.

Specifically, I have to update my version number in the source code (ie bump "vX.YZ" ) before I can tag it to be built.

---

So it seems I have a couple options

1. Continue bumping the build number manually before tagging
2. Have my CI update the build number (eg extract it from the tag) then commit the changes to master

In my opinion, bumping the version number manually is preferable because it requires more effort before deploying a release, and the releases are tied to the commit rather than being one commit behind in the case that CI has to update the version number. (Also I don't want to wait for a build to finish deploying before updating master )

I haven't been able to find a strong opinion online, so I'm curious:

Is it considered bad practice to have my CI build server commit into my repository?

Answer 1

Is it considered bad practice to have my CI build server commit into my repository?

It it not consider a bad practice, but it creates more complexity and security concerns that should be balanced from the benefits. Also remember that the process that you automate should be able to be executed manually in case of CI outage.

I think in your case there is a simpler solution. You could have the file in the source code that contains the version number not committed in the repository and be generated at build time from a script that pulls the latest tag. This way you would have a single point of truth for the release version (the tag) and the CI would not have to commit anything in the repository.

Answer 2

I would recommend the followings, if you can use vX.YZ BuildVersion versioning scheme.

1. Manage vX.YZ by manually based on Semantic Versioning policy.
2. CI makes a release package with settting BuildVersion , if you push a new tag to GitHub.
   It would be the incremental count.
   Please note that BuildVersion is not managed on GitHub.
3. CI pushes the package to GitHub Release.

Answer 3

Elaborating on the initial question, which is ampler than the tag example. Some times our CI modifies the content of the repo before producing an artifact. As an example imagine you have configuration files committed along with your application code. You normally would pack them together (eg in a Docker image) and then ship the image as the outcome of the build process. If your CI is modifying those files by changing some values how would you treat them?

• Commit the file back to the same repo without re-running the whole build would keep the config aligned but mess up the build process and might cause issues if the repo has been changed in the meantime.

• Use the new config in the final artifact would be very easy but the artifact would not reflect the actual content of the repo if you look back.

• Externalizing those artifacts to a new repo would be an option but breaks the best practice to minimize the number of dependencies you need to build your application.