Conditional workflow/job execution based on semvar commit messages

Build Environment
,
1

I have a project where the versions are updated via javascripts semvar library. These versions are then checked into code as well as having the tags for the sematic releases applied in github.

My problem is that this creates redundant workflows and releases. So suppose I merge a commit into a deployment branch. The folllowing will happen:

  1. tests run
  2. semvar updates versions and creates a git commit “task(release): ”
  3. build phase clones the repo and runs a build for the same commit prior to version update. Call this build A.
  4. the git commit from phase two triggers a test/build workflow with the version updates. Call this build B.

Build B is the correct build, since it has the incremented versions. Build A is incorrect since it doesn’t. The problem is I cant figure out a way to not run build A short of adding [no ci] in every commit, which is very irritating. The other very irritating option would be to run some shell commands prior to every other command to validate the git commit message matches a release spec - also a non starter.

My current solve for this is just to run redundant builds and have the subsequent build overwrite the prior one. The problem with this is that it creates a time window where the release version numbers are incorrect - which causes problems if the app tries to auto update in that timeframe.

I’m using GitHub, so I cant use GitLab’s extensive parameter set to match the commit messages.

2

@warrenronsiek we’re working on a solution that should hopefully make this setup easier for you. Any chance you’re willing to give some feedback via email to see if it fits your use case? If yes, can you email triggers-feedback@circleci.com?

3

Based on my experience with similar tools like semantic-release, at least, its defaults are to create the equivalent release commit with [skip ci] – if that doesn’t mess up some kind of downstream operation for you, you could consider adjusting the tool you’re using to make that task(release) commit with [skip ci] in the subject or in the first 200 characters of the body.

With CircleCI, you can still then run a workflow off the tag that presumably gets cut in step 2, and, if memory serves, the trigger will still execute even if the last commit on the tag has [skip ci] on it (note: Google Cloud Build and GitHub Actions behave a little differently in this situation).