Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
johntdyer opened this issue Nov 21, 2013 · 11 comments
Open

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

johntdyer opened this issue Nov 21, 2013 · 11 comments

Comments

@johntdyer
Copy link

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 [email protected]: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 [email protected]: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
Copy link
Author

Here is my metadata.rb... just incase

name             "monitor"
maintainer       "Tropo, Inc."
maintainer_email "[email protected]"
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
Copy link
Contributor

ivey commented Nov 21, 2013

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
Copy link
Author

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
Copy link
Author

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

@ivey
Copy link
Contributor

ivey commented Nov 23, 2013

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

@capoferro
Copy link
Contributor

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

@johntdyer
Copy link
Author

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 [email protected]:

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//issues/29#issuecomment-29120691
.

@capoferro
Copy link
Contributor

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

@johntdyer
Copy link
Author

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 [email protected]:

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//issues/29#issuecomment-29151189
.

@capoferro
Copy link
Contributor

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
Copy link
Contributor

ivey commented Nov 25, 2013

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants