auto tag does not appear to be working, probably user error

[johntdyer]

So I am not sure I am doing this right. I am especially not clear on what the following means.

If you include #major, #minor or #patch in the subject of commits, and run thor version:bump auto it will see if any major, minor or patch level changes are included since the last tag, and use the appropriate version. This works especially well with a CI server, allowing you to never have to directly manage versions at all. If no commits are tagged, the build number for the current version will be bumped instead.

As I understand it, I should be able to simply add #patch #major, or #minor in the commit message and thor-scmversion will handle the rest, but that doesnt seem to be the case for me....

So here is my setup. First off I have a tag on my repo ( 0.1.35 ). In my Thorfile I have a release task which you can see below:

  def release(type = 'auto')
    @current_version = nil
    system "git pull --rebase && git push"
    invoke "version:bump", [type]
    invoke "berkshelf:upload"
  end

When I pushed 0.1.35 everything seemed to work great, the first time.. However now it does not seem to be incrementing the versions like I expected. Example below:

jdyer@retina:~/Projects/chef/site-cookbooks/monitor(master○) » echo 3 >> commit
jdyer@retina:~/Projects/chef/site-cookbooks/monitor(master⚡) » git commit -am "testing thor-scmversion #patch"
[master fde8c89] testing thor-scmversion #patch
 1 file changed, 1 insertion(+)
jdyer@retina:~/Projects/chef/site-cookbooks/monitor(master○) » git push
Counting objects: 5, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 281 bytes | 0 bytes/s, done.
Total 3 (delta 1), reused 0 (delta 0)
To git@bitbucket.org:xxxxxx/monitor-chef.git
   e681b77..fde8c89  master -> master

jdyer@retina:~/Projects/chef/site-cookbooks/monitor(master○) » echo 4 >> commit

jdyer@retina:~/Projects/chef/site-cookbooks/monitor(master⚡) » git commit -am "testing thor-scmversion #patch"
[master 21d4c3f] testing thor-scmversion #patch
 1 file changed, 1 insertion(+)
jdyer@retina:~/Projects/chef/site-cookbooks/monitor(master○) » git push
Counting objects: 5, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 280 bytes | 0 bytes/s, done.
Total 3 (delta 1), reused 0 (delta 0)
To git@bitbucket.org:xxxxxx/monitor-chef.git
   fde8c89..21d4c3f  master -> master
jdyer@retina:~/Projects/chef/site-cookbooks/monitor(master○) »

You will not that I made a few commits with the #patch key in the commit message. On each of these commits my CI re-ran my release task. The problem is on both of these tests I berks upload ended up uploading 0.1.35. I was under the impression that it should have uploaded 0.1.36 and 0.1.37.

[johntdyer]

Here is my metadata.rb... just incase

name             "monitor"
maintainer       "Tropo, Inc."
maintainer_email "ops@tropo.com"
license          "Apache 2.0"
description      "A cookbook for monitoring services, using Sensu, a monitoring framework."
long_description IO.read(File.join(File.dirname(__FILE__), 'README.md'))
version          IO.read(File.join(File.dirname(__FILE__), 'VERSION')) rescue "0.0.1"

%w[
  ubuntu
  debian
  centos
  redhat
  fedora
].each do |os|
  supports os
end

depends "sensu"

and my VERSION file is in .gitignore

[ivey]

When this happens to us, it usually means the CI job can’t push tags. Do you have the output of thor version bumping in the CI run?

[johntdyer]

You are correct, the CI didn't have write, but it does now, which got me further. However now I am having another problem, my Jenkins server get's into a build loop.

• I do a commit
• Jenkins server bumps version, and the build is green
• this commit kicks off another post commit hook
• Jenkins does another build because of the commit hook.

I am not sure how to get around this....

[johntdyer]

@ivey Any thoughts ? Do u guys use commit hooks w/ this ?

[ivey]

I think I am missing something. Why is Jenkins committing?

[capoferro]

Jenkins should just be tagging the commit that it has just built, not creating a new commit.

[johntdyer]

So I am tagging a commit, and pushing to Bitbucket, which in turn sends a post to Jenkins. This is the trigger which kicks off the build. This first first build is tagged correctly and all is right in the world. The problem is when Jenkins pushes that tag upstream. This is what causes another build trigger post from bitbucket, which in turn kicks off another build... Round, and round, and round we go, where we'll stop, not even Jenkins knows ;)

On Fri, Nov 22, 2013 at 7:37 PM, Josiah Kiehl notifications@github.comwrote:

Jenkins should just be tagging the commit that it has just built, not creating a new commit.

— Reply to this email directly or view it on GitHubhttps://github.com/RiotGames/thor-scmversion/issues/29#issuecomment-29120691 .

[capoferro]

Ah ok. One fix would be to have Jenkins poll the repo for changes rather than have BitBucket initiate the build.

[johntdyer]

Is that really the solution ? My team generally shy's away from git polling.

On Sun, Nov 24, 2013 at 3:32 AM, Josiah Kiehl notifications@github.comwrote:

Ah ok. One fix would be to have Jenkins poll the repo for changes rather than have BitBucket initiate the build.

— Reply to this email directly or view it on GitHubhttps://github.com/RiotGames/thor-scmversion/issues/29#issuecomment-29151189 .

[capoferro]

At this point the problem is outside the domain of scmversion, so I don't know exactly what the best fix would be.

Given your builds trigger off tag pushes, and scmversion does versioning via tag pushes, you might be stuck trying to have BitBucket trigger builds.

[ivey]

We could check to see if the current version matches the current tag, and not change the version, since there's no changes. Would want it as an option but that might be a good thing.

PR welcome if we don't get around to doing that soon.