nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Hook/Add-On to execute custom actions on a merge on a pull-request

unknown

We have a use case where we would like to execute some custom actions when the "Merge" button is pushed in the Stash user interface. The end-goal is to update a version number that we can use in our gradle build scripts to be stamped in any builds done in our code.

Outside of Stash, we currently achieve this with pre-commit hooks, that modify our version number in a properties file. We have also tested and are considering using git tags instead. However, now that we've moved to stash. The "Merge" is handled outside of our local repos and thus our git hooks do not run. So I'm looking for some guidance. In Stash,

Is there a way (either via a hook) to tag a specific commit at merge time? I didn't find anything conclusive that suggested this was possible.
It seems it should be possible to write a hook that will modify a properties file, and ammend the commit. The thing about this solution that I'm not clear on is how/where the merge itself gets executed... The SDK exposes actions like git add and git commit, but are they run on the origin server itself? or elsewhere?

I hope my questions are clear! Thanks!

Accepted answers

All comments

jhinch (Atlassian)

I'm not sure if your requirements for a version number has to be incremental but you may be interested in using git describe --tags --always HEAD instead of updating a file every commit or creating many tags.

unknown

We do want our version number to change/increment with every merge to our main branch, but not necessarily every actual commit. We are in fact using the git describe, but it isn't helpful in this case.

We have Major.Minor.Patch-commit

- Major is manually updated

- Minor should be updated once per pull request/merge

- Patch is manually updated

- the commit number is taken from the git describe, so developers who are making multiple commits can track builds they make manually.

The minor number is the one we are interested in. I will look at doing some git describe or log magic to see if I can't extrapolate the same information.

unknown

We have Major.Minor.Patch-commit

- Major is manually updated

- Minor should be updated once per pull request/merge

- Patch is manually updated

- the commit number is taken from the git describe, so developers who are making multiple commits can track builds they make manually.

The minor number is the one we are interested in. I will look at doing some git describe or log magic to see if I can't extrapolate the same information.

cofarrell

Hi Jeremy,

How did you go with git describe?

I have to second Jason's suggestion. And perhaps to elaborate checking in the version into Git, while convenient for builds, is something that is going to be difficult to implement and is largely redundant given the information Git has. It should be possible to write a very simple plugin or build script that attaches a tag on each pull request merge, which will then assist your git describe (or whatever) to work out the minor version.

Here are some examples of people using git tags in Gradle.

https://github.com/palantir/gradle-gitsemver

http://ryanharter.com/blog/2013/07/30/automatic-versioning-with-git-and-gradle/

Good luck,

Charles

unknown

Hello, sorry for the delayed response. We did in the end go with a more automated version calculation using tags and git describe. The suggestion was good, put us on the right path. Our version number is tagged on releases and otherwise fully calculated via git describe.

cofarrell

Hi Jeremy. Glad to hear it.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

bitbucket-server

bitbucket-administration