CODEWITHSUNDEEP
git
PortMan
PortMan

Reputation: 4523

How to temporarily mark commits

How can I mark specific commits so that they can trigger actions on a server hook when they are pushed? For example, to trigger an automated build.

I can't just add the tag "build_this" to the commit, because tags have to be unique.

I could mark them with tags such as "build_thisXXXX", where XXXX is a unique string. But that's ugly and makes my skin crawl.

I could also have the server hook look for a keyword ("build_this") in the commit message, but that's even uglier, and is permanent.

Is there any other way mark a commit that will work for me?

-----EDITED TO ADD-------

OK, here's where I'm coming from on this issue:

I am investigating implementing something similar to the git-flow workflow pattern, as described here: http://jeffkreeftmeijer.com/2010/why-arent-you-using-git-flow/

In this pattern, I want developers to be able to trigger builds on the server for their feature branches. These feature branch builds can be used both for testing and for making sure that the feature branch code changes haven't broken the build before allowing them to be merged back into the development branch.

I don't want to trigger a build for any commit added to any branch, because I want developers to feel free to push changes to collaborate with each other without worrying about "breaking the build".

I could have them log into Jenkins and manually kick off a build for their branch, but that's a hassle for the developers.

So I'm wondering if there's a way to allow developers to kick off builds by marking their commits with a flag that says "build me!" that might be less of a hassle for the developers than logging in and manually starting the job.

Upvotes: 0

Views: 174

Answers (3)

Vasfed
Vasfed

Reputation: 18464

It's quite common when commit messages contain "tags" for issue tracking system (aka My great commit, this fixes #123, refs #321), so you can trigger a build on each commit that contains fixes # in message, as this implies that programmer thinks that commit will actually fix it and probably merge request will come just after

Upvotes: 0

Konrad Szałwiński
Konrad Szałwiński

Reputation: 400

It might be worth to consider using git flow pattern.

You can find more information here: http://jeffkreeftmeijer.com/2010/why-arent-you-using-git-flow/

All commits that goes either to master branch or develop branch will be compiled by the server.

Upvotes: 0

michas
michas

Reputation: 26555

This sounds a bit like an x-y-problem. A bit more background on you workflow would be helpful.

I would make my commits locally and whenever I am happy with my changes I push all my commits and let the server build the newest version. This way you can have a detailed commit history, but you only need to build the last commit of each push.

No need for "temporary" marks this way.

You could also define some "official" branches that are always build and some "exchange" branches that are never build.

You could also define a dedicate "build-me" branch. Then a developer could do something like:

git push -f HEAD:build-me

This would push the given commit to the server, and the server builds it. In this case this branch would have no other meaning that triggering manual builds.

Upvotes: 1

Related Questions