1

I am trying to update my git repo during the GoCD build. That means that because Go sees another change it triggers another build. Is it possible to stop the re-triggering of the build?

Background: I am building and publishing npm packages and I want to automatically increase the prerelease version so I don't have to remember it.

My pipeline looks essentially like this:

npm version prerelease --no-git-tag-version
npm publish
git add package.json
git commit -m "Bump prerelease version"
git push origin

This will update the version in git if the publish succeeds but also triggers another build since Go is polling.

Jens Elstner
  • 128
  • 1
  • 10

2 Answers2

0

Configure your CD/CI tool to build only when there is a commit to a specified branch or you can probably create a new branch called "pre-release" and configure CD/CI not to build when there is a commit.

Once this configuration is done in the CD/CI tool

npm version prerelease --no-git-tag-version
npm publish

// fetching for other branches
git fetch

// Switching your branch 
git checkout pre-release

// Finally committing
git add -m "Your commit message"
git push -u origin pre-release

I hope this works out for you :)

Sanjay Achar
  • 408
  • 4
  • 17
  • I guess this might work if I use a "prerelease" branch only to track the version changes. I would then have to merge this branch back into the main branch once in a while to keep the version there updated as well. – Jens Elstner Oct 30 '17 at 09:39
  • Yeah, you're right. But everything comes at the cost of time – Sanjay Achar Oct 30 '17 at 13:41
0

You can configure your stages in your pipeline to be triggered manually, for example, if you where setting up your pipelines as code, in your ${pipeline_name}.gocd.yaml.

  - deploy-to-next-stage:
      approval: manual            <-- You need this!
      jobs:
        deploy:
          tasks:
            ...

This may help as you could run an automated deploy to a development stage and then manually push successful builds to the next stage (pre-release perhaps). In this way, your builds that worked would not be effected by new builds being triggered by a push to your repo.

Or you could put this on your first stage and your entire pipeline would not be triggered by the push to the repo, but instead by you heading into the GUI and triggering it yourself.

Joe
  • 678
  • 9
  • 24