If info, ok := debug.A git commit is a snapshot of the repo at a particular point in time. The third solution to this problem is quite simple and comes fresh from the runtime/debug package, which is already part of the official Go library. Although I can see the benefits, I wouldn't recommend this for daily use. This way is mostly preferred when you are officially releasing a new stable version of your software, but not every time your merge a PR. This is something that is generated by the computer and not written by a person, so it's not uncommon for people to forget about it. However, the downside here is that you have to remember to include that file as part of your code well. If a component needs to know the version, now it has an easy way to find it: by reading this file. While this information is not that useful information for you (since you can also see this information in GitHub's user interface or just using git), the advantage here is that you can use this file for other things in your CI/CD environment as well. With this method, you have a file ( VERSION.txt) that always captures the latest commit hash of the repository. To avoid developing an unnecessary memory muscle, you can put this block into your Makefile, which is part of the target. You have to remember to run go generate every time before go build. For example: //go:generate sh -c "printf %s $(git rev-parse HEAD) > VERSION.txt" This process requires the installation of Go 1.16 or later, since it uses go:generate to populate the file contents and go:embed to populate the variable. Using go generateĪnother way is to use a file (let's call it VERSION.txt). You can make this easier by using Makefiles to do that for you. The disadvantage here is that you need to remember this syntax and run it every time you build your code. The most common way is by using a string variable, a value populated at build time via flags.įor example: var Commit string go build -ldflags="-X main.Commit=$(git rev-parse HEAD)" There are three ways to embed this hash into your Go program. This is when the git commit hash comes in handy. So what happens in the meantime? You do what the rolling-release model does, associating every build ( go build) with a snapshot of the code at that point in time. But this kind of progress doesn't happen in a day. You most likely already have automation in place to provide this information within your software (e.g., during the release pipeline). Of course, embedding the release version is not new. Usually, when a decent amount of progress has been made, a couple of features have been implemented and lots of bugs have been fixed, it's about time to make things official and announce a new release version of your software. To make sure you do not overwrite a previously saved record, git creates (by default) a unique identifier, hashed with the SHA-1 algorithm, for every commit. Whenever you want to capture a snapshot of the program's current codebase, you run a git commit command that saves the code at that point in time. To do that, you need a system that can control and manage different versions of the source code, such as git. They need to know what the source code looked like in previous versions, so they can debug any issues introduced at specific points in time. This information is essential, especially for developers. Whether you are using Go to write a simple console-based utility or a fancy web application, it is always helpful to reference the previous version of your software.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |