Get the Stash repository name from the environment for use in a custom git hook?

Question

We are currently using Git/Gitolite with an extensive range of GIT hooks written in Perl.

We are evaluating Stash but have some issues with trying to implement our existing hooks on stash managed repositories. I know there is a stash hook API but I'm not a developer and have no java experience, plus my existing hooks are tried and tested and do exactly what I need them to do.

I can get the user details from the REMOTE_USER variable and the hooks receive the normal STDIN from GIT.

The one thing that is missing is the repository name. If I printenv, i can see PWD set to a directory with a numeric name for my repository  ../repositories/stash_home/data/repositories/37 but the mapping between the directory name and the repository name is I assume held internal to stash.

Is there a way to get the repository name without the hook API?

Seems a pretty basic thing not to have, though admittedly it always does when it is something you rely on.

thanks a lot.

Ronan Cunningha · Answer

Hi Charles

Thanks for that. I have voted for the feature request. I've also worked out how to get the repo id by querying the environment for $GIT_PROJECT_ROOT then using this value to query the Stash rest API so I am good for now.

I can understand you guys have spent a lot of time working on the Hook API and want users to use it. At the risk of repeating myself, you may wish to allow for scenarios where companies may gradually progress to using the Hook API but may like to switch to Stash immediately for the enhanced user experience, while maintaining their back-end hook functionality.

When you ask " How much extra time do we invest in supporting scripts as well?"

I would say we have 900+ GIT users which could potentially equate to a 900+ Stash licenses if we can make Stash work in our environment. We have a lot of user interest for Stash at CME, but must make sure we can manage the GIT environment to our specific requirements so would like to think minor enhancements may be available if requested.

I'm speaking generally as I can work-around my specific issue in this instance, however, with respect, i wonder how much appreciation Atlassian have of the real enterprise environment given for example users with push permissions can delete tags and branches:

https://jira.atlassian.com/browse/STASH-2507

Plus there does not seem to be a way to automatically add non Hook API hooks automatically to new repositories created by Stash, via Stash.

I appreciate these are things that I specifically need, and admittedly can workaround fairly easily, but they seem fairly trivial to me, to the point where I question why they are not in the product by default as I imagine they would be common enough requirements.

I seems to me that Atlassian have focused a lot on the end user experience ( which is admittedly very good )but perhaps less so on what it mens to administer the product in a heavily controlled enterprise environment.

Anyway, I appreciate your your responses.

all the best

Ronan

cofarrell · Answer

Hi Ronan,

I've added a feature request that you might want to vote for and watch:

https://jira.atlassian.com/browse/STASH-3889

Cheers,

Charles

cofarrell · Answer

Hi Ronan,

Thanks for the explanation - we're always curious how people are using Stash and what custom hooks they have.

I completely understand that rewriting your current scripts isn't an option, or that all of our customers have the necessarily Java skills to write a plugin. It's really a trade off for us. There is so much more we can do in-process to allow people to create richer hooks, having access to the full suite of Stash services, permissions, application links (ie JIRA) etc. How much extra time do we invest in supporting scripts as well?

We certainly don't want to stop customers using their existing scripts, but ideally we can encourage (and even help write) new plugin hooks. They can then be shared with everyone on our marketplace for example; I don't think we would ever be able to do that if they were raw shell scripts.

In any case I'll talk to someone here about introducing a REPO_NAME environment variable. In the short term I hope my plugin lets you keep using your scripts without too much hassle?

Good luck.

Charles