We would like to implement a pre-commit hook to prevent users from committing too large files as this may be an issue in the long term (and some of our users are used to do it in other VCS)
I have looked at the examples and they seem simple enough. Also looked at this other question https://answers.atlassian.com/questions/145729/how-to-access-the-commit-message-in-pre-receive-hook that explains how to get to the commit message but what we would like to access is the individual changes' metadata, like name and size.
Is this possible at all? Of course we would like to reject the push in case any of the changes/files is larger than what we allow.
I couldn't help myself, I've put together an example plugin which should do the trick.
It's worth re-iterating that for each branch being pushed there are going to be _three_ git calls invoked on the server. This is not an entirely free operation and you may potentially see a small lag for each push. Testing it locally with some small commits seems very snappy, but I just want to warn you up-front.
Let me know if you have any trouble or thoughts.
That's a tricky question. Getting the file names is relatively easy with the current API.
At this point things get a little complicated. Up until this point you've only had to use our high-level API, and more importantly you've only had to make two low-level Git calls (which is one too many really). With the information you have here you _could_ restrict commits based on a set of file extensions. So for example on a Java project you probably never want to allow '.jar' files, regardless of the size. For your use-case this might be enough.
If you want to work out the filesize then you'll need to start making manual Git calls (ie this but in Java). Unfortunaty we don't have a high-level, or even medium-level API on which you can retrieve the Git blob (ie file) sizes from. However with the current scm-git API (ie low-level) you _could_ do:
I've skipped proper error handling and all that stuff. Sorry I don't have time right now to actually code this in an example plugin. It's actually a really good idea for a plugin and it would make a good example of how to use our scm API. This is the kind of thing we have to do regularly to implement our high-level APIs (like HistoryService).
There _may_ be a better way to do this, in which case I apologise in advance if I lead you astray. I hope this helps.
As a Belgian, beer-lover and home brewer, beer is one of my great passions. I love the fact that with just a few ingredients (usually just water, hop and malt) you can create so many different tastes...
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
We're bringing product updates and pro tips on teamwork to ten cities around the world.Save your spot