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.
Just the FAQs! Welcome to the Community, and this Focused-FAQ! Here, we've pulled together some of the most frequently asked questions associated with Jira Service Desk (JSD). We hope ...
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