Reputation: 1472
Simple shell script question. Setting up pipelines in BB and one of the jobs I am porting over is to increment a bower version via some grunt commands. I had this broken up into separate jobs so that it would not auto-run because it bumps the package, and commits back to the repo. So what I am trying to do is when the tasks start, run a git log command, check the last commit message and if it matches a pre-defined message then just exit. Otherwise continue on. How do I check the latest git commit message and run an if else check in bash?
#! /bin/bash
git log -1
if git log -1 === "pre-defined message";
then
echo "already pushed and bumped exiting"
exit 1
else
echo "not bumped -- continuing job"
./setup-git.sh
fi
Upvotes: 1
Views: 8399
Reputation: 1472
Found the solution that seems to satisfy what I need out of pipelines although I need to setup different shell scripts to not run the npm installs if the message is already received:
#! /bin/bash
MESSAGE=$(git log -1 HEAD --pretty=format:%s)
if [[ "$MESSAGE" == "This goes into next release" ]]; then
echo "already pushed run grunt and exit"
grunt build
echo "nothing to see here -- move along"
else
echo "not bumped -- continuing job"
git config --global user.email "[email protected]"
git config --global user.name "Blah Blah"
git remote set-url origin https://user:[email protected]/myawesomegitrepo.git
grunt releaseme
git config --global push.default matching
git commit dist/destro -m "This goes into next release"
git push --tags
fi
Credit to James Nine for his answer on this thread: How to capture a git commit message and run an action
Upvotes: 1
Reputation: 1413
What I believe you're trying to do is ignore certain commits from causing a build or other steps....and while this might work fine in a manual build environment, standard build tools are going to be problematic.
I struggled with this in Jenkins, support files used and modified as part of the build would trigger a build when committed back to the repo, resulting in an never-ending build cycle.
My solution was to separate the repo into the source in one directory, the supporting files in another, and then add an exclude region for Jenkins such that commits generated by the build didn't cause the next poll to do anything (because the files committed have nothing to do with the actual project being build). A little obtuse, but seems to work.
And if that's not what you were asking, actually ask a question and then we contributors have a context to work with!
Upvotes: 1