Missed Team ’24? Catch up on announcements here.

×
Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Chaining BitBucket repos by triggering commit in one repo after completion of another repo Pipeline

Bryan Copeland May 20, 2019

My use-case is to try to restore "Smart Commits" by writing a script for doing the same. We lost the ability to use Smart Commits because they would lead to duplicate logging of hours with our new Branching Models and Merge Strategy workflows (squash all commits, merge rebase --force update, etc)... since we are rewriting history by that strategy, the BitBucket-JIRA integration will not have a reference to the historical original SmartCommit built-in to prevent duplicates, since the history SHA won't be found due to the rewrite.

Yes I know the perils of rewriting history but for better or worse this is our strategy for the time being. To get some automated commenting, time tracking, workflow transitions, etc going again in our repo, we will need to do this in our pipeline:

SMART_COMMIT=`git log ${BITBUCKET_COMMIT} -n 1 --abbrev-commit --pretty=format:"%h - %an, %ar --- %s" | sed -e 's/\~time/\#time/g' -e 's/\~comment/\#comment/g' -e 's/\~move-to-test/\#move-to-test/g' -e 's/^.*ago --- //'`
echo ${SMART_COMMIT} >> CHANGELOG.md
git add CHANGELOG.md
git commit -m --author="${COMMIT_AUTHOR}" "${SMART_COMMIT} [skip ci]"
git push origin "${CURRENT_BRANCH}"


Basically I would need to replace that last line's ${CURRENT_BRANCH} with a specific branch (say "master") in another private "TimeTracking" repository within the same organization's list of Projects/Repos, this repo does nothing but wait for changes in a "CHANGELOG.md" file. I've tested that manually and it works fine. Now I need to trigger it in an automated manner from my original repo's BitBucket Pipelines, basically chaining the 2nd repo's BitBucket Pipeline to kick in and log the SmartCommit one time (by doing this only on specific "non-integration" branches we'll both get the hours logged right away when the change pushes from a Dev's local to remote, and, we'll avoid duplicates since we won't run it on "develop", "release/*" or "master").

I'm not sure the best approach to do this, but from what I've been finding in searches my options may be limited to the BitBucket Cloud API remotely making an update to the "CHANGELOG.md" file, doing something odd with an API Key-based CURL request of the changelog changed in the original branch as a "build artifcat" that gets POST'd over to the other TimeTracking repo plus some kind of listener or polling of "Downloads" in the 2nd repo or scheduled approach... but I'm not giving up hope that there might be a reasonably simpler way to go about it.

Can anyone provide a basic example of pushing some tiny update to another repo from a separate first repo's BitBucket Pipeline run? Is it possible to just checkout a 2nd repo and commit back to it? I know committing back to the same repo just came out very recently, so that could be a stretch...

1 answer

0 votes
davina
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
June 25, 2019

Hi @Bryan Copeland 

You might find the Trigger pipeline pipe useful! Check out our Bitbucket pipes and scroll down to Trigger pipeline.

Interested in your feedback if you find it helpful :)

Davina

Suggest an answer

Log in or Sign up to answer
TAGS
AUG Leaders

Atlassian Community Events