CODEWITHSUNDEEP
gitshellbitbucket-pipelines
isaac weathers
isaac weathers

Reputation: 1472

Check git log with shell script

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

Answers (2)

isaac weathers
isaac weathers

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

Scott Sosna
Scott Sosna

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

Related Questions