So the option I explored involves hardcoding values into
src/Build/Version.h.cmake. That may not end up being the best solution but I think a lot of what I found still applies.
The three values that problematically show "Unknown" normally look something like:
Code: Select all
#define FCRevision "9571 (Git)" //Highest committed revision number
#define FCRevisionDate "2017/01/08 17:48:14" //Date of highest committed revision
#define FCRepositoryURL "https://github.com/FreeCAD/FreeCAD master" //Repository URL of the working copy
So, if we want to hardcode them using git hooks, we have a bit of a problem. GitHub doesn't allow post-receive hooks because that would allow arbitrary execution of code on their servers. Normally a post-receive hook is what we'd want, since the alternative is hardcoding values before a tag is pushed. That, however, also has issues because files in
.git/hooks are not included in the repository, so they'd have to have a new folder outside of
.git and some script would have to unpack them into the hooks dir.
Besides that, things seem promising. Let's assume we are using a post-receive hook, since that's what I tested using
this guide.
Let's say I'm a committer and I want to push the newest version of 0.16. I can run the following commands:
Code: Select all
g tag -f 0.16 # force updating
g push origin :refs/tags/0.16 # delete on remote
g push origin 0.16 # push tag pointed at new commit
A post-receive hook will see a commit coming in on branch
refs/tags/0.16 and it will have that commit hash. The following one-liners will generate the revision number and date of that committed revision, in the same format as shown above:
Code: Select all
echo $(git show-ref refs/tags/0.16 | cut -d' ' -f 1) "(Git)"
git show --pretty=format:"%cd" --date=format:"%Y/%m/%d %H:%M:%S" $(git show-ref refs/tags/0.16 | cut -d' ' -f 1) | head -n 1
So, it's definitely possible to insert those values into the script with git hooks. The problems are whether that's the right solution, and then choosing between
- using a developer-side pre-push hook that will need to be moved into place somehow, preferably without adding hassle
- using a server-side post-receive hook. this means github will send a webhook with the post-receive payload to, for example, the webhook server I've been working on. the downside is that this will add another commit as the webhook server pushes the hardcoded file commit, and so every tagged release will actually be showing "commit number + 1". so on second thought it looks like we'll have to go with the first option.
Sorry for the rambling post, just wanted to offload what I've found so far.