Added -v flag and makefile for application version #4

asdf · 2019-09-22T04:30:24Z

asdf commented

2019-09-22 04:30:24 +00:00

This update adds:

v tag to print version and build information
makefile to set version and build information from:
git tag for version
date for build

To support the version information, the software must now be built using the makefile (i.e. make). If go build is used, some fallback information is displayed.

Documentation has been updated to advise regarding the makefile.

Some notes:

the makefile is very basic but can be improved later
i haven't tested the install section, and this PR should test the tag

As always, if you have a preferred method of doing anything let me know and I'll update it.

This update adds: - v tag to print version and build information - makefile to set version and build information from: - git tag for version - date for build To support the version information, the software must now be built using the makefile (i.e. `make`). If `go build` is used, some fallback information is displayed. Documentation has been updated to advise regarding the makefile. Some notes: - the makefile is very basic but can be improved later - i haven't tested the install section, and this PR should test the tag As always, if you have a preferred method of doing anything let me know and I'll update it.

sloum commented

2019-09-22 18:04:41 +00:00

I do not understand a lot of what is going on, but it does seem to mostly work. I get the following output for make install:

fatal: No names found, cannot describe anything.
go install -ldflags "-s -X main.version= -X main.build=2019-09-22T10:59-07:00"

I get the same fatal warning when doing make clean. Would a make uninstall make sense for this?

EDIT: I just saw where you said that install was not tested. This all makes sense then.
I do not believe we have any tags explicitly set, so it just uses the build tag, but I can confirm that it gets a version. I get the following output for gfu -v:

gfu - gophermap format utility - version  build 2019-09-22T10:59-07:00

Which looks good to me. I'm happy to merge this in, or if we wanted to wait until the rest of the makefile was tested out and worked through I can add a release branch for this and we can merge all updates into that, pending a release?

Let me know your preference.

I do not understand a lot of what is going on, but it does seem to mostly work. I get the following output for `make install`: ``` fatal: No names found, cannot describe anything. go install -ldflags "-s -X main.version= -X main.build=2019-09-22T10:59-07:00" ``` I get the same fatal warning when doing `make clean`. Would a `make uninstall` make sense for this? EDIT: I just saw where you said that `install` was not tested. This all makes sense then. I do not believe we have any tags explicitly set, so it just uses the build tag, but I can confirm that it gets a version. I get the following output for `gfu -v`: ``` gfu - gophermap format utility - version build 2019-09-22T10:59-07:00 ``` Which looks good to me. I'm happy to merge this in, or if we wanted to wait until the rest of the makefile was tested out and worked through I can add a release branch for this and we can merge all updates into that, pending a release? Let me know your preference.

asdf commented

2019-09-23 02:10:23 +00:00

That error is coming from git describe --tags failing. gfu -v output should be:

gfu - gophermap format utility - version (git tag) build (compile datetime)

I had a tag set for the version, and attempted to push it with this branch. Your experience raises two issues:

The tag has not come through for you, and I'm not sure why.
If git describe --tags fails, there is no fallback, so the version field is empty.
Let me have a look in to this further.

I think make uninstall would be really useful and should be present if make install is present. I'll add it in.

In terms of testing, I am manually executing the commands using a standard user account. All the make targets work for me. I thought make install would not work, but it actually does, although it only putting the binary in my go bin directory. A privileged account installing to /usr/local/bin or whatever might work differently, and I can't test this currently.

That error is coming from `git describe --tags` failing. `gfu -v` output should be: gfu - gophermap format utility - version (git tag) build (compile datetime) I had a tag set for the version, and attempted to push it with this branch. Your experience raises two issues: - The tag has not come through for you, and I'm not sure why. - If git `describe --tags fails`, there is no fallback, so the version field is empty. Let me have a look in to this further. I think `make uninstall` would be really useful and should be present if `make install` is present. I'll add it in. In terms of testing, I am manually executing the commands using a standard user account. All the make targets work for me. I thought `make install` would not work, but it actually does, although it only putting the binary in my go bin directory. A privileged account installing to `/usr/local/bin` or whatever might work differently, and I can't test this currently.

sloum commented

2019-09-23 03:05:19 +00:00

I believe with the later (trying to isntall into /usr/local/bin that running sudo make install would transfer the sudo privileges down to the install command. So that should work as well.

I believe with the later (trying to isntall into `/usr/local/bin` that running `sudo make install` would transfer the sudo privileges down to the install command. So that _should_ work as well.

asdf commented

2019-09-24 02:05:50 +00:00

I saw your notes regarding branches with tags, and also have been reading A successful git branching model. It would be good to operate this repo in the same way you are setting up for bombadillo.

Regarding the error you had when the tag was not found, I found this commit which describes a fallback for tag issues, or non-git users. If git describe --tags fails, the version is read from the VERSION file.

Still working on the above, but I've implemented make uninstall.

I saw your notes regarding branches with tags, and also have been reading [A successful git branching model](https://nvie.com/posts/a-successful-git-branching-model/). It would be good to operate this repo in the same way you are setting up for bombadillo. Regarding the error you had when the tag was not found, I found [this commit](https://github.com/mvp/uhubctl/commit/e93d1a06a217b59d64d3ce40dcc3e003433fbb31) which describes a fallback for tag issues, or non-git users. If `git describe --tags` fails, the version is read from the `VERSION` file. Still working on the above, but I've implemented `make uninstall`.

sloum commented

2019-09-24 04:30:51 +00:00

I skimmed the beginning of the article (I am on baby duty right now, so was not able to fully focus); it looks good. I have used a few different git branching models in my professional life... but for personal projects have generally just stuck to a constant push into master from feature branches. With Bombadillo and now gfu both picking up steam and working with other developers I think it very appropriate to have structured and organized releases. I dont know that many people are depending on them currently, but I'd like to think that both tools could build up a little steam. I know Bombadillo is used by a decent number of people. I def want to finish the article, tomorrow is likely.

Awesome. That makes sense to me. In theory they should generally line up, I suppose. But the git route, being automated, does make things easier.

Awesome re: uninstall. I, as a rule, think uninstall is a great thing to have (except when a program was installed via package manager. I think they should remove via package manager in that case).

This is looking great!

I skimmed the beginning of the article (I am on baby duty right now, so was not able to fully focus); it looks good. I have used a few different git branching models in my professional life... but for personal projects have generally just stuck to a constant push into master from feature branches. With Bombadillo and now gfu both picking up steam and working with other developers I think it very appropriate to have structured and organized releases. I dont know that many people are depending on them currently, but I'd like to think that both tools could build up a little steam. I know Bombadillo is used by a decent number of people. I def want to finish the article, tomorrow is likely. Awesome. That makes sense to me. In theory they should generally line up, I suppose. But the git route, being automated, does make things easier. Awesome re: uninstall. I, as a rule, think uninstall is a great thing to have (except when a program was installed via package manager. I think they should remove via package manager in that case). This is looking great!

asdf commented

2019-09-24 11:00:37 +00:00

Version is recorded as a tag as well as in the VERSION file. If there is an issue with the git tag, or the source is not downloaded via git clone, the version is read from the VERSION file. A manual process is required to update VERSION to ensure it matches the git tag.

It looks like a tag has been pushed to my fork on tildegit, but am not sure if this will merge here. I'm still not too sure on the process to set this up.

Makefile should be good to go.

Version is recorded as a tag as well as in the VERSION file. If there is an issue with the git tag, or the source is not downloaded via `git clone`, the version is read from the VERSION file. A manual process is required to update VERSION to ensure it matches the git tag. It looks like a tag has been pushed to my fork on tildegit, but am not sure if this will merge here. I'm still not too sure on the process to set this up. Makefile should be good to go.

sloum commented

2019-09-24 15:11:44 +00:00

Awesome. I can merge in and we can see? I know you can update commits to a tag after the fact. I'll also set up a develop branch.