git repository - get label from a specified branch
I'm using the Git source control plugin to get the most recent code in a specific release branch, by using the <branch>...</branch> element.
By following the CCNET server log, I can see the git repository is cloned, and later the specified branch is checked out. So far, so good.
Problems started when I added a custom labeller that builds the CcNet label from the Git last tag by using git describe: label would not reflect the last tag placed on the release branch, but a previous one.Going back to the CCNET server log, I found out that the sequence seems to be:
- repository is cloned or updated
- labeller is invoked
- branch specified in CCNET configuration is checked out
As a workaround, I added to my custom labeller the ability of doing a git checkout to a specified branch before issuing the git describe. But maybe it would be better if in the above sequence, labeller was invoked after the checkout.
A full description of the scenario is posted here.
Thanks for the great job you are doing with this tool.
We're working on adding custom properties from tasks, source controls actions, etc. So the git task can add some more information like hash, abbrev. hash, git describe, etc.
Maybe this helps a bit. It does not solve the "wrong order of the ccnet workflow" ;)
Also created issue #266 -> Change inner Workflow of CCNet to support such scenarios
RE: git repository - get label from a specified branch - Added by Emanuel Wlaschitz about 4 years ago
According to git blame, the build order described in issue #266 (create label -> run prebuild -> update source) is from around 2006. Does anyone know by chance why this order was chosen by then?
I can't think of anything a prebuild could/would do before updating the source. Infact, some things that should happen before our actual build are placed in the build section, just before the actual msbuild block (because the prebuild is run before the update, causing changes from prebuild such as copying of prerequisite libraries to end up as pointless action reverted by the subsequent VCS update).
As far as I can see, that would be the only reason why the label is generated first; because the prebuild may fail. And if it weren't for the prebuild, I'd simply go and move things around to go
1. update source
2. create label
3. run prebuild
...and then the rest.
On the other hand, that might be a breaking change; as I don't know if anyone knows about this and knowingly uses it to do things...