Yet Another Way To Implement Commit Metadata

Yet Another Way To Implement Commit Metadata

What is the issue?


This is something I’m being asked many times:

<font color=blue>how can I pass metadata along with a git commit (‘sender’) in order to use it in some other step of the process (‘receiver’) while this data is not part of the basic git information passed with this commit?</font>

For example, If I want - for the current commit - to activate a certain Jenkins job (e.g. run regression tests) once it is pushed and gets to the Jenkins server, while I don’t want to activate this job for other commits.

What are the options for implementing this?


Usually I considered 2 options - that I know of - as a solution for this request:

  1. Passing certain command in the commit message - e.g. ‘activate regression tests’ (as were done in many SVN-related solutions).
  2. Use Git Notes, which seems that were built exactly for that purpose but it very hard to understand and use.

But there is another option - using git tags - that seems to me much cleaner, clearer and appripiate for this task. I’m not saying that you shouldn’t use the other 2 options, but you should consider using that one as well.

Yet another way to implement…


The way to do it is very simple:

  • On the ‘sender’ side - add a meaningful tag to the latest commit that will be pushed.
  • On the ‘receiver’ side - check whether there is a tag pointing to the latest commit on the pulled commits.

More detailed implementation

On the 'sender' side:

After and only after you perform the last changes commit before you push the changes, you should add a tag that its text contains the scope and details of required metadata. For example, if you want to run regression tests and it is related to Jira ticket RND-1111, then you should tag it as such:

git tag RND-1111_run-regression-tests

If the tag is reusable, you must first delete it from the remote repository. For the above example, run:

git push origin :RND-1111_run-regression-tests

Then you push the new tag (or if you have more metadata-tags):

git push origin --tags

Of course, you can wrap those commands inside a script that gets the tag name as argument. For example:

function tagpush() { echo `git push origin :$1` || true && git tag -f $1 && git push origin --tags }

On the 'reciever' side:

After you clone or update the repository locally and checkout the relevant commit, you can fetch the tags locally as well:

git fetch --tags

Related to the above example, if your current commit sha1 is stored as SHA1 variable, and your current Jira issue is stored as ISSUE variable, you can not check whether you need to run the regression tests as follow:

COUNT_TAG_TESTS=`git tag --contains $SHA1 | $ISSUE_run-regression-tests | wc -l` || true
if [[ $COUNT_TAG_TESTS > 0 ]]; then RUN_REGRESSION_TESTS=true; else RUN_REGRESSION_TESTS=false; fi

And that’s it! You’re ready to go!

  • Sometimes it is best to delete the tags after being used - unless you want to keep it in the history for audit reasons
  • If there are more than one tag used for the same commit, it is best to have the SHA1 or other scope-item (e.g. Jira issue ID) as a folder-like level in the tag name, e.g. git tag $SHA1/run-regression-tests $SHA1/regression-tests-server-server1


  • Feedbacks on the post are more than welcome!!!
  • I will be glad to see your replies.
  • Do you have any related tip on this subject to share as well?
  • Any questions about it?
  • I’ll be glad to help!

Yoram Michaeli

DevOps Fullstack Tech Leader

DevOps Group