Hello
we are using Bitbucket for a couple of projects, and we have added a pre-receive hook that checks the commits message for the presence of a valid JIRA issue : the script parses each commit message, extract JIRA issue references (must find at least one), and check the issues are in "In Progress" status. If one commit does not satisfy the rules, the push is rejected.
This works fine for development: the developer creates a JIRA issues, commit changes with respect to it, pushes, then closes the JIRA issue once done.
But when a user wants to reintegrate the changes made to another branch, then the script hook will check again the commit messages and reject it because the JIRA issue is closed.
*Example*:
- Developer A makes 5 commits on branch A with a valid JIRA-Ticket A
- Developer A pushes the 5 commits to the repository
- Developer A closes the ticket because the feature is done
- Developer B works on branch B and merges branch A into his branch to get the latest feature
- The 5 commits done by Developer A are now part of branch B with their commit-message referencing JIRA-Ticket A
- Developer B tries to push his merged branch B into the repository
- Developer B gets an error message because there are commits in his push that reference the already-closed JIRA-Ticket A
A similar problem is produced when Pull Requests are merged using the BitBucket Web-UI. The commits that perform the merge do have auto-generated commit messages without a JIRA Ticket. When a developer merges these commits into his working branch, the next pull will fail because the commits he now has in his branch do not have a jira ticket.
Is there a way to work around this? Is there a way to exclude merge and pull request commits from the pre-receive hook ?
Regards
Did you write your own pre-receive hook, or are you using one of the plugins in marketplace.atlassian.com to accomplish this?
I think our free Control Freak plugin will meet all your needs here. In particular select Control Freak's "[x] - Ignore merge commits" option.
Also, Control Freak never re-checks previously validated commits, and so when branch B merges in previously validated commits from branch A, Control Freak knows to skip those.
@Julius Davies [bit-booster.com] what is the control freak setup for:
"only committing against a Jira issue “in progress”. If a Jira issue has been moved to the state of "verified" and more changes are being made, it needs be moved back to the "in progress" state before more changes can be committed again.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.