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.
We generally try to encourage people to use our rich hook/plugin API. Unfortunately we realise that means it's a little more difficult to migrate actual 'scripts'.
If you just want the repository name then you can install a simple plugin I wrote that writes out the repository slug to a 'name' file within each repository (although it doesn't handle things like forks).
Let me know if you have any questions/problems.
Just out of curiosity what kinds of hooks do you currently have?
Thanks for the response. I will look into the plugin. It should probably do what I need, though Ideally I would have a dynamic option rather than reading a static filename.
I've also found the Atlassian Stash REST API where I can make a rest call and parse the returned data, mapping it to the ID of the GIT_PROJECT_ROOT variable.
Our pre & post receive hooks are all written in Perl and spawn many different processes. They rely on the username, repo name and Git STDIN. Our environment is heavily focused on information security/regulatory requirements (Financial Services) and our hooks work and are robust. 4 plus years of scripting/testing/implementation, to completely rewrite all that functionality using the plugin api is not trivial.
So I can get the data I need, though Ideally I would look up a dynamic variable at hook run time. There are several stash variables in the environment, GIT_PROJECT_ROOT, REMOTE_USER etc so REPO_NAME would be nice.
Not everyone administering Stash will have the java skills to use the plugin api or the time and resources to convert existing tried and tested scripts.
thanks for replying
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?
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:
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
This community is celebrating its one-year anniversary and Atlassian co-founder Mike Cannon-Brookes has all the feels.Read more
Bitbucket Pipelines helps me manage and automate a number of serverless deployments to AWS Lambda and this is how I do it. I'm building Node.js Lambda functions using node-lambda ...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs