Open johntdyer opened 10 years ago
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
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?
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 am not sure how to get around this....
@ivey Any thoughts ? Do u guys use commit hooks w/ this ?
I think I am missing something. Why is Jenkins committing?
Jenkins should just be tagging the commit that it has just built, not creating a new commit.
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 .
Ah ok. One fix would be to have Jenkins poll the repo for changes rather than have BitBucket initiate the build.
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 .
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.
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.
So I am not sure I am doing this right. I am especially not clear on what the following means.
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:
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:
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.