[hard] problem building github tags

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

[hard] problem building github tags

Samuel Henrique
Hello,

I'm trying to make jenkins trigger a build whenever a new tag is pushed to my git repo.

I already made it to trigger builds when a tag pointing to a new commit is pushed, by setting:

refspec: +refs/tags/*:refs/remotes/origin/tags/*
branch specifier: **

The problem is that the builds are not triggered when i tag some commit that already has another tag, even if its an annotated tag.

The use case is as follows:

1)We need devs to be able to deploy our webapp by tagging releases on github (mostly in other branches than master), like tag: v1.0.0 (the previous tag was v0.9.9).
2)We need to be able to rollback deploys, by tagging again previous releases (rollbacks will be always tagging commits on master), like tag: v0.9.9-rollback [ponting to the same commit as v0.9.9).
3)We also need to follow some process that would allow fresh servers to retrieve the same deployed release as the other servers (dealing with autoscalling/dynamic inventory)

The 3rd item is easily solvable by configuring capistrano to self-deploy the last tag (sorting tags by taggerdate) on server startup (so new machines will fetch rollbacks too).

The 1st item is already good, as jenkins always trigger a build when a tag ponting to a new commit is pushed.

My problem is with rollbacks (2nd item), jenkins will receive the git hook, poll the repository but won't trigger the build, it detects the new tag but it acts as it already built that.

I've searched online and from what i read, i think the git plugin is checking the hash the tag points to, not the hash from the tag itself, thus it doesn't detect a change. Can somebody confirm if i'm right, or if the problem is is another plugin?

Any help is highly appreciated.

--
You received this message because you are subscribed to the Google Groups "Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/735cc770-d406-41b6-a16f-29b946a5d441%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: [hard] problem building github tags

Mark Waite-2


On Friday, July 14, 2017 at 7:56:00 AM UTC-8, Samuel Henrique wrote:
Hello,

I'm trying to make jenkins trigger a build whenever a new tag is pushed to my git repo.

I already made it to trigger builds when a tag pointing to a new commit is pushed, by setting:

refspec: +refs/tags/*:refs/remotes/origin/tags/*
branch specifier: **

The problem is that the builds are not triggered when i tag some commit that already has another tag, even if its an annotated tag.

The use case is as follows:

1)We need devs to be able to deploy our webapp by tagging releases on github (mostly in other branches than master), like tag: v1.0.0 (the previous tag was v0.9.9).
2)We need to be able to rollback deploys, by tagging again previous releases (rollbacks will be always tagging commits on master), like tag: v0.9.9-rollback [ponting to the same commit as v0.9.9).
3)We also need to follow some process that would allow fresh servers to retrieve the same deployed release as the other servers (dealing with autoscalling/dynamic inventory)

The 3rd item is easily solvable by configuring capistrano to self-deploy the last tag (sorting tags by taggerdate) on server startup (so new machines will fetch rollbacks too).

The 1st item is already good, as jenkins always trigger a build when a tag ponting to a new commit is pushed.

My problem is with rollbacks (2nd item), jenkins will receive the git hook, poll the repository but won't trigger the build, it detects the new tag but it acts as it already built that.

I've searched online and from what i read, i think the git plugin is checking the hash the tag points to, not the hash from the tag itself, thus it doesn't detect a change. Can somebody confirm if i'm right, or if the problem is is another plugin?


That is correct.  The git plugin assumes that once it has built a commit, then it does not need to build it again.

There are alternatives that may allow you to force a build of an already built commit.  For instance, you could parameterize a build to take the tag of the commit to build as an argument, then invoke it with a POST from the "curl" command to build that specific tag.  That isn't as elegant as the webhook technique that you're trying to use, since it requires that you create something that detects the creation of a new tag, then when the new tag is detected, it calls that curl command.

Mark Waite
 
Any help is highly appreciated.

--
You received this message because you are subscribed to the Google Groups "Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/75931016-ab78-40c5-90a9-309d88b1bcbf%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: [hard] problem building github tags

ahammond
One of the fundamental concepts in CI/CD is "build once". So... we build for every commit and test. Code which we want to promote, we merge and then test again. If tests pass, we tag it with a release number in git (v3.2 for example) and push that. I expect jenkins to fire a build. Our jenkinsfile will then do a docker pull and discover it's already built, apply the new tag and docker push.

But it sounds like this workflow is fundamentally not possible with Jenkins. Is that correct?

A

On Friday, July 14, 2017 at 9:00:10 AM UTC-7, Mark Waite wrote:


On Friday, July 14, 2017 at 7:56:00 AM UTC-8, Samuel Henrique wrote:
Hello,

I'm trying to make jenkins trigger a build whenever a new tag is pushed to my git repo.

I already made it to trigger builds when a tag pointing to a new commit is pushed, by setting:

refspec: +refs/tags/*:refs/remotes/origin/tags/*
branch specifier: **

The problem is that the builds are not triggered when i tag some commit that already has another tag, even if its an annotated tag.

The use case is as follows:

1)We need devs to be able to deploy our webapp by tagging releases on github (mostly in other branches than master), like tag: v1.0.0 (the previous tag was v0.9.9).
2)We need to be able to rollback deploys, by tagging again previous releases (rollbacks will be always tagging commits on master), like tag: v0.9.9-rollback [ponting to the same commit as v0.9.9).
3)We also need to follow some process that would allow fresh servers to retrieve the same deployed release as the other servers (dealing with autoscalling/dynamic inventory)

The 3rd item is easily solvable by configuring capistrano to self-deploy the last tag (sorting tags by taggerdate) on server startup (so new machines will fetch rollbacks too).

The 1st item is already good, as jenkins always trigger a build when a tag ponting to a new commit is pushed.

My problem is with rollbacks (2nd item), jenkins will receive the git hook, poll the repository but won't trigger the build, it detects the new tag but it acts as it already built that.

I've searched online and from what i read, i think the git plugin is checking the hash the tag points to, not the hash from the tag itself, thus it doesn't detect a change. Can somebody confirm if i'm right, or if the problem is is another plugin?


That is correct.  The git plugin assumes that once it has built a commit, then it does not need to build it again.

There are alternatives that may allow you to force a build of an already built commit.  For instance, you could parameterize a build to take the tag of the commit to build as an argument, then invoke it with a POST from the "curl" command to build that specific tag.  That isn't as elegant as the webhook technique that you're trying to use, since it requires that you create something that detects the creation of a new tag, then when the new tag is detected, it calls that curl command.

Mark Waite
 
Any help is highly appreciated.

--
You received this message because you are subscribed to the Google Groups "Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/3438e084-53c4-467e-9cdb-7c84acae60de%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: [hard] problem building github tags

ahammond
Oh, to clarify, we're using the "github branch source" plugin and I have already confirmed that github is correctly firing the webhook.

On Wednesday, September 6, 2017 at 4:38:05 PM UTC-7, [hidden email] wrote:
One of the fundamental concepts in CI/CD is "build once". So... we build for every commit and test. Code which we want to promote, we merge and then test again. If tests pass, we tag it with a release number in git (v3.2 for example) and push that. I expect jenkins to fire a build. Our jenkinsfile will then do a docker pull and discover it's already built, apply the new tag and docker push.

But it sounds like this workflow is fundamentally not possible with Jenkins. Is that correct?

A

On Friday, July 14, 2017 at 9:00:10 AM UTC-7, Mark Waite wrote:


On Friday, July 14, 2017 at 7:56:00 AM UTC-8, Samuel Henrique wrote:
Hello,

I'm trying to make jenkins trigger a build whenever a new tag is pushed to my git repo.

I already made it to trigger builds when a tag pointing to a new commit is pushed, by setting:

refspec: +refs/tags/*:refs/remotes/origin/tags/*
branch specifier: **

The problem is that the builds are not triggered when i tag some commit that already has another tag, even if its an annotated tag.

The use case is as follows:

1)We need devs to be able to deploy our webapp by tagging releases on github (mostly in other branches than master), like tag: v1.0.0 (the previous tag was v0.9.9).
2)We need to be able to rollback deploys, by tagging again previous releases (rollbacks will be always tagging commits on master), like tag: v0.9.9-rollback [ponting to the same commit as v0.9.9).
3)We also need to follow some process that would allow fresh servers to retrieve the same deployed release as the other servers (dealing with autoscalling/dynamic inventory)

The 3rd item is easily solvable by configuring capistrano to self-deploy the last tag (sorting tags by taggerdate) on server startup (so new machines will fetch rollbacks too).

The 1st item is already good, as jenkins always trigger a build when a tag ponting to a new commit is pushed.

My problem is with rollbacks (2nd item), jenkins will receive the git hook, poll the repository but won't trigger the build, it detects the new tag but it acts as it already built that.

I've searched online and from what i read, i think the git plugin is checking the hash the tag points to, not the hash from the tag itself, thus it doesn't detect a change. Can somebody confirm if i'm right, or if the problem is is another plugin?


That is correct.  The git plugin assumes that once it has built a commit, then it does not need to build it again.

There are alternatives that may allow you to force a build of an already built commit.  For instance, you could parameterize a build to take the tag of the commit to build as an argument, then invoke it with a POST from the "curl" command to build that specific tag.  That isn't as elegant as the webhook technique that you're trying to use, since it requires that you create something that detects the creation of a new tag, then when the new tag is detected, it calls that curl command.

Mark Waite
 
Any help is highly appreciated.

--
You received this message because you are subscribed to the Google Groups "Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/2add8404-567b-400d-baa2-2562cebe867f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: [hard] problem building github tags

Mark Waite-2
The current git plugin does not provide a convenient way to build something that has been tagged if it has already been built.  If you're willing to be on the cutting edge, you could install a pull request build of Stephen Connolly's work to add richer support for tags.

There are ways to force a build of something that has already been built (for example, parameterize a build with the SHA1 to be built and the tag to be applied).  I think that is close to what you're seeking, since your multi-branch pipeline evaluates every change, but you want to make a later decision if that build should be promoted.

I'm not sure that is entirely what you're seeking, but it is closer to what you're seeking.

Mark Waite

On Wed, Sep 6, 2017 at 5:43 PM <[hidden email]> wrote:
Oh, to clarify, we're using the "github branch source" plugin and I have already confirmed that github is correctly firing the webhook.


On Wednesday, September 6, 2017 at 4:38:05 PM UTC-7, [hidden email] wrote:
One of the fundamental concepts in CI/CD is "build once". So... we build for every commit and test. Code which we want to promote, we merge and then test again. If tests pass, we tag it with a release number in git (v3.2 for example) and push that. I expect jenkins to fire a build. Our jenkinsfile will then do a docker pull and discover it's already built, apply the new tag and docker push.

But it sounds like this workflow is fundamentally not possible with Jenkins. Is that correct?

A

On Friday, July 14, 2017 at 9:00:10 AM UTC-7, Mark Waite wrote:


On Friday, July 14, 2017 at 7:56:00 AM UTC-8, Samuel Henrique wrote:
Hello,

I'm trying to make jenkins trigger a build whenever a new tag is pushed to my git repo.

I already made it to trigger builds when a tag pointing to a new commit is pushed, by setting:

refspec: +refs/tags/*:refs/remotes/origin/tags/*
branch specifier: **

The problem is that the builds are not triggered when i tag some commit that already has another tag, even if its an annotated tag.

The use case is as follows:

1)We need devs to be able to deploy our webapp by tagging releases on github (mostly in other branches than master), like tag: v1.0.0 (the previous tag was v0.9.9).
2)We need to be able to rollback deploys, by tagging again previous releases (rollbacks will be always tagging commits on master), like tag: v0.9.9-rollback [ponting to the same commit as v0.9.9).
3)We also need to follow some process that would allow fresh servers to retrieve the same deployed release as the other servers (dealing with autoscalling/dynamic inventory)

The 3rd item is easily solvable by configuring capistrano to self-deploy the last tag (sorting tags by taggerdate) on server startup (so new machines will fetch rollbacks too).

The 1st item is already good, as jenkins always trigger a build when a tag ponting to a new commit is pushed.

My problem is with rollbacks (2nd item), jenkins will receive the git hook, poll the repository but won't trigger the build, it detects the new tag but it acts as it already built that.

I've searched online and from what i read, i think the git plugin is checking the hash the tag points to, not the hash from the tag itself, thus it doesn't detect a change. Can somebody confirm if i'm right, or if the problem is is another plugin?


That is correct.  The git plugin assumes that once it has built a commit, then it does not need to build it again.

There are alternatives that may allow you to force a build of an already built commit.  For instance, you could parameterize a build to take the tag of the commit to build as an argument, then invoke it with a POST from the "curl" command to build that specific tag.  That isn't as elegant as the webhook technique that you're trying to use, since it requires that you create something that detects the creation of a new tag, then when the new tag is detected, it calls that curl command.

Mark Waite
 
Any help is highly appreciated.

--
You received this message because you are subscribed to the Google Groups "Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/2add8404-567b-400d-baa2-2562cebe867f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/CAO49JtHVrYxoLktg7g4LYotf09WTQin_V_eVq5UMi84CN9Fk7A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: [hard] problem building github tags

stephenconnolly
In reply to this post by ahammond

You could build the plugin with the PR merged and do some testing to help give better confidence for releasing that PR


On Thu 7 Sep 2017 at 00:43, <[hidden email]> wrote:
Oh, to clarify, we're using the "github branch source" plugin and I have already confirmed that github is correctly firing the webhook.


On Wednesday, September 6, 2017 at 4:38:05 PM UTC-7, [hidden email] wrote:
One of the fundamental concepts in CI/CD is "build once". So... we build for every commit and test. Code which we want to promote, we merge and then test again. If tests pass, we tag it with a release number in git (v3.2 for example) and push that. I expect jenkins to fire a build. Our jenkinsfile will then do a docker pull and discover it's already built, apply the new tag and docker push.

But it sounds like this workflow is fundamentally not possible with Jenkins. Is that correct?

A

On Friday, July 14, 2017 at 9:00:10 AM UTC-7, Mark Waite wrote:


On Friday, July 14, 2017 at 7:56:00 AM UTC-8, Samuel Henrique wrote:
Hello,

I'm trying to make jenkins trigger a build whenever a new tag is pushed to my git repo.

I already made it to trigger builds when a tag pointing to a new commit is pushed, by setting:

refspec: +refs/tags/*:refs/remotes/origin/tags/*
branch specifier: **

The problem is that the builds are not triggered when i tag some commit that already has another tag, even if its an annotated tag.

The use case is as follows:

1)We need devs to be able to deploy our webapp by tagging releases on github (mostly in other branches than master), like tag: v1.0.0 (the previous tag was v0.9.9).
2)We need to be able to rollback deploys, by tagging again previous releases (rollbacks will be always tagging commits on master), like tag: v0.9.9-rollback [ponting to the same commit as v0.9.9).
3)We also need to follow some process that would allow fresh servers to retrieve the same deployed release as the other servers (dealing with autoscalling/dynamic inventory)

The 3rd item is easily solvable by configuring capistrano to self-deploy the last tag (sorting tags by taggerdate) on server startup (so new machines will fetch rollbacks too).

The 1st item is already good, as jenkins always trigger a build when a tag ponting to a new commit is pushed.

My problem is with rollbacks (2nd item), jenkins will receive the git hook, poll the repository but won't trigger the build, it detects the new tag but it acts as it already built that.

I've searched online and from what i read, i think the git plugin is checking the hash the tag points to, not the hash from the tag itself, thus it doesn't detect a change. Can somebody confirm if i'm right, or if the problem is is another plugin?


That is correct.  The git plugin assumes that once it has built a commit, then it does not need to build it again.

There are alternatives that may allow you to force a build of an already built commit.  For instance, you could parameterize a build to take the tag of the commit to build as an argument, then invoke it with a POST from the "curl" command to build that specific tag.  That isn't as elegant as the webhook technique that you're trying to use, since it requires that you create something that detects the creation of a new tag, then when the new tag is detected, it calls that curl command.

Mark Waite
 
Any help is highly appreciated.

--
You received this message because you are subscribed to the Google Groups "Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/2add8404-567b-400d-baa2-2562cebe867f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
Sent from my phone

--
You received this message because you are subscribed to the Google Groups "Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/CA%2BnPnMyKyg8OBdC%2B0%3D6%2BPeHqaQFQMvdZ4p%3DP9RqwZdtivQWY4Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: [hard] problem building github tags

stephenconnolly

On Thu 7 Sep 2017 at 07:22, Stephen Connolly <[hidden email]> wrote:

You could build the plugin with the PR merged and do some testing to help give better confidence for releasing that PR


On Thu 7 Sep 2017 at 00:43, <[hidden email]> wrote:
Oh, to clarify, we're using the "github branch source" plugin and I have already confirmed that github is correctly firing the webhook.

Hmmm the event side of that PR may need updating... 

Would be really good to see if tags get created by events or if they only show on an index with the current PR



On Wednesday, September 6, 2017 at 4:38:05 PM UTC-7, [hidden email] wrote:
One of the fundamental concepts in CI/CD is "build once". So... we build for every commit and test. Code which we want to promote, we merge and then test again. If tests pass, we tag it with a release number in git (v3.2 for example) and push that. I expect jenkins to fire a build. Our jenkinsfile will then do a docker pull and discover it's already built, apply the new tag and docker push.

But it sounds like this workflow is fundamentally not possible with Jenkins. Is that correct?

A

On Friday, July 14, 2017 at 9:00:10 AM UTC-7, Mark Waite wrote:


On Friday, July 14, 2017 at 7:56:00 AM UTC-8, Samuel Henrique wrote:
Hello,

I'm trying to make jenkins trigger a build whenever a new tag is pushed to my git repo.

I already made it to trigger builds when a tag pointing to a new commit is pushed, by setting:

refspec: +refs/tags/*:refs/remotes/origin/tags/*
branch specifier: **

The problem is that the builds are not triggered when i tag some commit that already has another tag, even if its an annotated tag.

The use case is as follows:

1)We need devs to be able to deploy our webapp by tagging releases on github (mostly in other branches than master), like tag: v1.0.0 (the previous tag was v0.9.9).
2)We need to be able to rollback deploys, by tagging again previous releases (rollbacks will be always tagging commits on master), like tag: v0.9.9-rollback [ponting to the same commit as v0.9.9).
3)We also need to follow some process that would allow fresh servers to retrieve the same deployed release as the other servers (dealing with autoscalling/dynamic inventory)

The 3rd item is easily solvable by configuring capistrano to self-deploy the last tag (sorting tags by taggerdate) on server startup (so new machines will fetch rollbacks too).

The 1st item is already good, as jenkins always trigger a build when a tag ponting to a new commit is pushed.

My problem is with rollbacks (2nd item), jenkins will receive the git hook, poll the repository but won't trigger the build, it detects the new tag but it acts as it already built that.

I've searched online and from what i read, i think the git plugin is checking the hash the tag points to, not the hash from the tag itself, thus it doesn't detect a change. Can somebody confirm if i'm right, or if the problem is is another plugin?


That is correct.  The git plugin assumes that once it has built a commit, then it does not need to build it again.

There are alternatives that may allow you to force a build of an already built commit.  For instance, you could parameterize a build to take the tag of the commit to build as an argument, then invoke it with a POST from the "curl" command to build that specific tag.  That isn't as elegant as the webhook technique that you're trying to use, since it requires that you create something that detects the creation of a new tag, then when the new tag is detected, it calls that curl command.

Mark Waite
 
Any help is highly appreciated.

--
You received this message because you are subscribed to the Google Groups "Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/2add8404-567b-400d-baa2-2562cebe867f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
Sent from my phone
--
Sent from my phone

--
You received this message because you are subscribed to the Google Groups "Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/CA%2BnPnMziyUkD1HUOm9rs8brdE%3DACPYNe8e27bh0PrqzGWZTh4A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: [hard] problem building github tags

stephenconnolly


On 6 September 2017 at 23:24, Stephen Connolly <[hidden email]> wrote:

On Thu 7 Sep 2017 at 07:22, Stephen Connolly <[hidden email]> wrote:

You could build the plugin with the PR merged and do some testing to help give better confidence for releasing that PR


On Thu 7 Sep 2017 at 00:43, <[hidden email]> wrote:
Oh, to clarify, we're using the "github branch source" plugin and I have already confirmed that github is correctly firing the webhook.

Hmmm the event side of that PR may need updating... 

Would be really good to see if tags get created by events or if they only show on an index with the current PR

Had a look at the code, tag events were not being handled, so I pushed https://github.com/jenkinsci/github-branch-source-plugin/pull/158/commits/51fc6efbfed92f541032ed672be2ee9d9ac2e398 which should provide event support for tags

Now if you want tags to build automatically, then you will need to write an extension plugin for branch-api that provides an implementation of https://github.com/jenkinsci/branch-api-plugin/blob/master/src/main/java/jenkins/branch/BranchBuildStrategy.java (one there is at least one BranchBuildStrategy extension defined in your Jenkins then the BranchSource should allow you to add the strategies: https://github.com/jenkinsci/branch-api-plugin/blob/master/src/main/resources/jenkins/branch/BranchSource/config.jelly#L45 Note though, https://github.com/jenkinsci/branch-api-plugin/blob/22c8d12a5ad3b523042343bb769b15affb11d1a6/src/main/java/jenkins/branch/MultiBranchProject.java#L2162-L2173 so if you configure a source with one or more BranchBuildStrategy instances then that source will stop using the default behaviour of auto-build anything that is not a tag, so you might need more than one strategy to provide the flexibility you want
 



On Wednesday, September 6, 2017 at 4:38:05 PM UTC-7, [hidden email] wrote:
One of the fundamental concepts in CI/CD is "build once". So... we build for every commit and test. Code which we want to promote, we merge and then test again. If tests pass, we tag it with a release number in git (v3.2 for example) and push that. I expect jenkins to fire a build. Our jenkinsfile will then do a docker pull and discover it's already built, apply the new tag and docker push.

But it sounds like this workflow is fundamentally not possible with Jenkins. Is that correct?

A

On Friday, July 14, 2017 at 9:00:10 AM UTC-7, Mark Waite wrote:


On Friday, July 14, 2017 at 7:56:00 AM UTC-8, Samuel Henrique wrote:
Hello,

I'm trying to make jenkins trigger a build whenever a new tag is pushed to my git repo.

I already made it to trigger builds when a tag pointing to a new commit is pushed, by setting:

refspec: +refs/tags/*:refs/remotes/origin/tags/*
branch specifier: **

The problem is that the builds are not triggered when i tag some commit that already has another tag, even if its an annotated tag.

The use case is as follows:

1)We need devs to be able to deploy our webapp by tagging releases on github (mostly in other branches than master), like tag: v1.0.0 (the previous tag was v0.9.9).
2)We need to be able to rollback deploys, by tagging again previous releases (rollbacks will be always tagging commits on master), like tag: v0.9.9-rollback [ponting to the same commit as v0.9.9).
3)We also need to follow some process that would allow fresh servers to retrieve the same deployed release as the other servers (dealing with autoscalling/dynamic inventory)

The 3rd item is easily solvable by configuring capistrano to self-deploy the last tag (sorting tags by taggerdate) on server startup (so new machines will fetch rollbacks too).

The 1st item is already good, as jenkins always trigger a build when a tag ponting to a new commit is pushed.

My problem is with rollbacks (2nd item), jenkins will receive the git hook, poll the repository but won't trigger the build, it detects the new tag but it acts as it already built that.

I've searched online and from what i read, i think the git plugin is checking the hash the tag points to, not the hash from the tag itself, thus it doesn't detect a change. Can somebody confirm if i'm right, or if the problem is is another plugin?


That is correct.  The git plugin assumes that once it has built a commit, then it does not need to build it again.

There are alternatives that may allow you to force a build of an already built commit.  For instance, you could parameterize a build to take the tag of the commit to build as an argument, then invoke it with a POST from the "curl" command to build that specific tag.  That isn't as elegant as the webhook technique that you're trying to use, since it requires that you create something that detects the creation of a new tag, then when the new tag is detected, it calls that curl command.

Mark Waite
 
Any help is highly appreciated.

--
You received this message because you are subscribed to the Google Groups "Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/2add8404-567b-400d-baa2-2562cebe867f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
Sent from my phone
--
Sent from my phone

--
You received this message because you are subscribed to the Google Groups "Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/CA%2BnPnMy03%3DzAQ4V%2Be89omSXe29%2B5751YwQpRSBL-2teDQCSP%2BA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: [hard] problem building github tags

Knurek
I've got version 2.2.4 of GitHub Branch Source Plugin installed, and
compiled, installed, and configured my organization folder to use https://github.com/AngryBytes/jenkins-build-everything-strategy-plugin
which uses:
     @Override
    public boolean isAutomaticBuild(SCMSource source, SCMHead head) {
        return true;
    }

then I run a Scan the organization folder, but don't see any mention to the tags. What's up with that? Is there something else missing along the way?

Examining org/repo

  Checking branches...

  Getting remote branches...

    Checking branch feature/publishers
      ‘Jenkinsfile’ found
    Met criteria
No changes detected: feature/publishers (still at a29373c2e692bf549f7ff114e4be6ed82f7d056d)

    Checking branch master
      ‘Jenkinsfile’ found
    Met criteria
No changes detected: master (still at a9bc55ee5d6e82111f6ca70ea6168da9289ddd12)

    Checking branch test
      ‘Jenkinsfile’ found
    Met criteria
No changes detected: test (still at b224b0276df138020efed0d1545f97c4bff294cd)

  3 branches were processed

  Checking pull-requests...

  Getting remote pull requests...

  0 pull requests were processed

Finished examining org/repo




On Thursday, 7 September 2017 11:43:41 UTC+2, Stephen Connolly wrote:


On 6 September 2017 at 23:24, Stephen Connolly <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="aPQk8bKpAQAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">stephen.al...@gmail.com> wrote:

On Thu 7 Sep 2017 at 07:22, Stephen Connolly <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="aPQk8bKpAQAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">stephen.al...@gmail.com> wrote:
You are waiting on <a href="https://github.com/jenkinsci/github-branch-source-plugin/pull/158" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fjenkinsci%2Fgithub-branch-source-plugin%2Fpull%2F158\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHHhD34lpD2GN6sIudMzReSkRphog&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fjenkinsci%2Fgithub-branch-source-plugin%2Fpull%2F158\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHHhD34lpD2GN6sIudMzReSkRphog&#39;;return true;">https://github.com/jenkinsci/github-branch-source-plugin/pull/158 to be merged then.

You could build the plugin with the PR merged and do some testing to help give better confidence for releasing that PR


On Thu 7 Sep 2017 at 00:43, <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="aPQk8bKpAQAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">aham...@...> wrote:
Oh, to clarify, we're using the "github branch source" plugin and I have already confirmed that github is correctly firing the webhook.

Hmmm the event side of that PR may need updating... 

Would be really good to see if tags get created by events or if they only show on an index with the current PR

Had a look at the code, tag events were not being handled, so I pushed <a href="https://github.com/jenkinsci/github-branch-source-plugin/pull/158/commits/51fc6efbfed92f541032ed672be2ee9d9ac2e398" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fjenkinsci%2Fgithub-branch-source-plugin%2Fpull%2F158%2Fcommits%2F51fc6efbfed92f541032ed672be2ee9d9ac2e398\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGVGi8ocXpAU_vbJ0RivSgLGCTyVg&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fjenkinsci%2Fgithub-branch-source-plugin%2Fpull%2F158%2Fcommits%2F51fc6efbfed92f541032ed672be2ee9d9ac2e398\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGVGi8ocXpAU_vbJ0RivSgLGCTyVg&#39;;return true;">https://github.com/jenkinsci/github-branch-source-plugin/pull/158/commits/51fc6efbfed92f541032ed672be2ee9d9ac2e398 which should provide event support for tags

Now if you want tags to build automatically, then you will need to write an extension plugin for branch-api that provides an implementation of <a href="https://github.com/jenkinsci/branch-api-plugin/blob/master/src/main/java/jenkins/branch/BranchBuildStrategy.java" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fjenkinsci%2Fbranch-api-plugin%2Fblob%2Fmaster%2Fsrc%2Fmain%2Fjava%2Fjenkins%2Fbranch%2FBranchBuildStrategy.java\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFunIBM-mYtQMWcZSgkfXTevEYRgQ&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fjenkinsci%2Fbranch-api-plugin%2Fblob%2Fmaster%2Fsrc%2Fmain%2Fjava%2Fjenkins%2Fbranch%2FBranchBuildStrategy.java\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFunIBM-mYtQMWcZSgkfXTevEYRgQ&#39;;return true;">https://github.com/jenkinsci/branch-api-plugin/blob/master/src/main/java/jenkins/branch/BranchBuildStrategy.java (one there is at least one BranchBuildStrategy extension defined in your Jenkins then the BranchSource should allow you to add the strategies: <a href="https://github.com/jenkinsci/branch-api-plugin/blob/master/src/main/resources/jenkins/branch/BranchSource/config.jelly#L45" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fjenkinsci%2Fbranch-api-plugin%2Fblob%2Fmaster%2Fsrc%2Fmain%2Fresources%2Fjenkins%2Fbranch%2FBranchSource%2Fconfig.jelly%23L45\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNF-phE6_Y4cqAhyRJ58TLQkHQrbJA&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fjenkinsci%2Fbranch-api-plugin%2Fblob%2Fmaster%2Fsrc%2Fmain%2Fresources%2Fjenkins%2Fbranch%2FBranchSource%2Fconfig.jelly%23L45\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNF-phE6_Y4cqAhyRJ58TLQkHQrbJA&#39;;return true;">https://github.com/jenkinsci/branch-api-plugin/blob/master/src/main/resources/jenkins/branch/BranchSource/config.jelly#L45 Note though, <a href="https://github.com/jenkinsci/branch-api-plugin/blob/22c8d12a5ad3b523042343bb769b15affb11d1a6/src/main/java/jenkins/branch/MultiBranchProject.java#L2162-L2173" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fjenkinsci%2Fbranch-api-plugin%2Fblob%2F22c8d12a5ad3b523042343bb769b15affb11d1a6%2Fsrc%2Fmain%2Fjava%2Fjenkins%2Fbranch%2FMultiBranchProject.java%23L2162-L2173\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNF-jaSKFkK13o-4YSNWOzwwaDvcNA&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fjenkinsci%2Fbranch-api-plugin%2Fblob%2F22c8d12a5ad3b523042343bb769b15affb11d1a6%2Fsrc%2Fmain%2Fjava%2Fjenkins%2Fbranch%2FMultiBranchProject.java%23L2162-L2173\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNF-jaSKFkK13o-4YSNWOzwwaDvcNA&#39;;return true;">https://github.com/jenkinsci/branch-api-plugin/blob/22c8d12a5ad3b523042343bb769b15affb11d1a6/src/main/java/jenkins/branch/MultiBranchProject.java#L2162-L2173 so if you configure a source with one or more BranchBuildStrategy instances then that source will stop using the default behaviour of auto-build anything that is not a tag, so you might need more than one strategy to provide the flexibility you want
 



On Wednesday, September 6, 2017 at 4:38:05 PM UTC-7, [hidden email] wrote:
One of the fundamental concepts in CI/CD is "build once". So... we build for every commit and test. Code which we want to promote, we merge and then test again. If tests pass, we tag it with a release number in git (v3.2 for example) and push that. I expect jenkins to fire a build. Our jenkinsfile will then do a docker pull and discover it's already built, apply the new tag and docker push.

But it sounds like this workflow is fundamentally not possible with Jenkins. Is that correct?

A

On Friday, July 14, 2017 at 9:00:10 AM UTC-7, Mark Waite wrote:


On Friday, July 14, 2017 at 7:56:00 AM UTC-8, Samuel Henrique wrote:
Hello,

I'm trying to make jenkins trigger a build whenever a new tag is pushed to my git repo.

I already made it to trigger builds when a tag pointing to a new commit is pushed, by setting:

refspec: +refs/tags/*:refs/remotes/origin/tags/*
branch specifier: **

The problem is that the builds are not triggered when i tag some commit that already has another tag, even if its an annotated tag.

The use case is as follows:

1)We need devs to be able to deploy our webapp by tagging releases on github (mostly in other branches than master), like tag: v1.0.0 (the previous tag was v0.9.9).
2)We need to be able to rollback deploys, by tagging again previous releases (rollbacks will be always tagging commits on master), like tag: v0.9.9-rollback [ponting to the same commit as v0.9.9).
3)We also need to follow some process that would allow fresh servers to retrieve the same deployed release as the other servers (dealing with autoscalling/dynamic inventory)

The 3rd item is easily solvable by configuring capistrano to self-deploy the last tag (sorting tags by taggerdate) on server startup (so new machines will fetch rollbacks too).

The 1st item is already good, as jenkins always trigger a build when a tag ponting to a new commit is pushed.

My problem is with rollbacks (2nd item), jenkins will receive the git hook, poll the repository but won't trigger the build, it detects the new tag but it acts as it already built that.

I've searched online and from what i read, i think the git plugin is checking the hash the tag points to, not the hash from the tag itself, thus it doesn't detect a change. Can somebody confirm if i'm right, or if the problem is is another plugin?


That is correct.  The git plugin assumes that once it has built a commit, then it does not need to build it again.

There are alternatives that may allow you to force a build of an already built commit.  For instance, you could parameterize a build to take the tag of the commit to build as an argument, then invoke it with a POST from the "curl" command to build that specific tag.  That isn't as elegant as the webhook technique that you're trying to use, since it requires that you create something that detects the creation of a new tag, then when the new tag is detected, it calls that curl command.

Mark Waite
 
Any help is highly appreciated.

--
You received this message because you are subscribed to the Google Groups "Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="javascript:" target="_blank" gdf-obfuscated-mailto="aPQk8bKpAQAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">jenkinsci-use...@googlegroups.com.
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/jenkinsci-users/2add8404-567b-400d-baa2-2562cebe867f%40googlegroups.com?utm_medium=email&amp;utm_source=footer" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/d/msgid/jenkinsci-users/2add8404-567b-400d-baa2-2562cebe867f%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/msgid/jenkinsci-users/2add8404-567b-400d-baa2-2562cebe867f%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;">https://groups.google.com/d/msgid/jenkinsci-users/2add8404-567b-400d-baa2-2562cebe867f%40googlegroups.com.
For more options, visit <a href="https://groups.google.com/d/optout" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;">https://groups.google.com/d/optout.
--
Sent from my phone
--
Sent from my phone

--
You received this message because you are subscribed to the Google Groups "Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/d90508e3-95e4-42a9-99be-70d75ae54da0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: [hard] problem building github tags

stephenconnolly
2.2.4 does not have discovery of tags merged yet

On 1 November 2017 at 08:15, <[hidden email]> wrote:
I've got version 2.2.4 of GitHub Branch Source Plugin installed, and
compiled, installed, and configured my organization folder to use https://github.com/AngryBytes/jenkins-build-everything-strategy-plugin
which uses:
     @Override
    public boolean isAutomaticBuild(SCMSource source, SCMHead head) {
        return true;
    }

then I run a Scan the organization folder, but don't see any mention to the tags. What's up with that? Is there something else missing along the way?

Examining org/repo

  Checking branches...

  Getting remote branches...

    Checking branch feature/publishers
      ‘Jenkinsfile’ found
    Met criteria
No changes detected: feature/publishers (still at a29373c2e692bf549f7ff114e4be6ed82f7d056d)

    Checking branch master
      ‘Jenkinsfile’ found
    Met criteria
No changes detected: master (still at a9bc55ee5d6e82111f6ca70ea6168da9289ddd12)

    Checking branch test
      ‘Jenkinsfile’ found
    Met criteria
No changes detected: test (still at b224b0276df138020efed0d1545f97c4bff294cd)

  3 branches were processed

  Checking pull-requests...

  Getting remote pull requests...

  0 pull requests were processed

Finished examining org/repo




On Thursday, 7 September 2017 11:43:41 UTC+2, Stephen Connolly wrote:


On 6 September 2017 at 23:24, Stephen Connolly <[hidden email]> wrote:

On Thu 7 Sep 2017 at 07:22, Stephen Connolly <[hidden email]> wrote:

You could build the plugin with the PR merged and do some testing to help give better confidence for releasing that PR


On Thu 7 Sep 2017 at 00:43, <[hidden email]> wrote:
Oh, to clarify, we're using the "github branch source" plugin and I have already confirmed that github is correctly firing the webhook.

Hmmm the event side of that PR may need updating... 

Would be really good to see if tags get created by events or if they only show on an index with the current PR

Had a look at the code, tag events were not being handled, so I pushed https://github.com/jenkinsci/github-branch-source-plugin/pull/158/commits/51fc6efbfed92f541032ed672be2ee9d9ac2e398 which should provide event support for tags

Now if you want tags to build automatically, then you will need to write an extension plugin for branch-api that provides an implementation of https://github.com/jenkinsci/branch-api-plugin/blob/master/src/main/java/jenkins/branch/BranchBuildStrategy.java (one there is at least one BranchBuildStrategy extension defined in your Jenkins then the BranchSource should allow you to add the strategies: https://github.com/jenkinsci/branch-api-plugin/blob/master/src/main/resources/jenkins/branch/BranchSource/config.jelly#L45 Note though, https://github.com/jenkinsci/branch-api-plugin/blob/22c8d12a5ad3b523042343bb769b15affb11d1a6/src/main/java/jenkins/branch/MultiBranchProject.java#L2162-L2173 so if you configure a source with one or more BranchBuildStrategy instances then that source will stop using the default behaviour of auto-build anything that is not a tag, so you might need more than one strategy to provide the flexibility you want
 



On Wednesday, September 6, 2017 at 4:38:05 PM UTC-7, [hidden email] wrote:
One of the fundamental concepts in CI/CD is "build once". So... we build for every commit and test. Code which we want to promote, we merge and then test again. If tests pass, we tag it with a release number in git (v3.2 for example) and push that. I expect jenkins to fire a build. Our jenkinsfile will then do a docker pull and discover it's already built, apply the new tag and docker push.

But it sounds like this workflow is fundamentally not possible with Jenkins. Is that correct?

A

On Friday, July 14, 2017 at 9:00:10 AM UTC-7, Mark Waite wrote:


On Friday, July 14, 2017 at 7:56:00 AM UTC-8, Samuel Henrique wrote:
Hello,

I'm trying to make jenkins trigger a build whenever a new tag is pushed to my git repo.

I already made it to trigger builds when a tag pointing to a new commit is pushed, by setting:

refspec: +refs/tags/*:refs/remotes/origin/tags/*
branch specifier: **

The problem is that the builds are not triggered when i tag some commit that already has another tag, even if its an annotated tag.

The use case is as follows:

1)We need devs to be able to deploy our webapp by tagging releases on github (mostly in other branches than master), like tag: v1.0.0 (the previous tag was v0.9.9).
2)We need to be able to rollback deploys, by tagging again previous releases (rollbacks will be always tagging commits on master), like tag: v0.9.9-rollback [ponting to the same commit as v0.9.9).
3)We also need to follow some process that would allow fresh servers to retrieve the same deployed release as the other servers (dealing with autoscalling/dynamic inventory)

The 3rd item is easily solvable by configuring capistrano to self-deploy the last tag (sorting tags by taggerdate) on server startup (so new machines will fetch rollbacks too).

The 1st item is already good, as jenkins always trigger a build when a tag ponting to a new commit is pushed.

My problem is with rollbacks (2nd item), jenkins will receive the git hook, poll the repository but won't trigger the build, it detects the new tag but it acts as it already built that.

I've searched online and from what i read, i think the git plugin is checking the hash the tag points to, not the hash from the tag itself, thus it doesn't detect a change. Can somebody confirm if i'm right, or if the problem is is another plugin?


That is correct.  The git plugin assumes that once it has built a commit, then it does not need to build it again.

There are alternatives that may allow you to force a build of an already built commit.  For instance, you could parameterize a build to take the tag of the commit to build as an argument, then invoke it with a POST from the "curl" command to build that specific tag.  That isn't as elegant as the webhook technique that you're trying to use, since it requires that you create something that detects the creation of a new tag, then when the new tag is detected, it calls that curl command.

Mark Waite
 
Any help is highly appreciated.

--
You received this message because you are subscribed to the Google Groups "Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/2add8404-567b-400d-baa2-2562cebe867f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
Sent from my phone
--
Sent from my phone

--
You received this message because you are subscribed to the Google Groups "Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/d90508e3-95e4-42a9-99be-70d75ae54da0%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/CA%2BnPnMzUCgfNEOULYKZYAC%2Bxg2RChf_%2BWFkVdkQ-8Deiv0USBg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: [hard] problem building github tags

Knurek
ah, well that explains it :)

I should have paid more attention that the PR is still open https://github.com/jenkinsci/github-branch-source-plugin/pull/158/


On Wednesday, 1 November 2017 16:54:22 UTC+1, Stephen Connolly wrote:
2.2.4 does not have discovery of tags merged yet

On 1 November 2017 at 08:15, <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="uFDRQVphAwAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">j.kn...@...> wrote:
I've got version 2.2.4 of GitHub Branch Source Plugin installed, and
compiled, installed, and configured my organization folder to use <a href="https://github.com/AngryBytes/jenkins-build-everything-strategy-plugin" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2FAngryBytes%2Fjenkins-build-everything-strategy-plugin\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFZ4N0SLh8qcULAx1-Awsiz6i59vw&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2FAngryBytes%2Fjenkins-build-everything-strategy-plugin\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFZ4N0SLh8qcULAx1-Awsiz6i59vw&#39;;return true;">https://github.com/AngryBytes/jenkins-build-everything-strategy-plugin
which uses:
     @Override
    public boolean isAutomaticBuild(SCMSource source, SCMHead head) {
        return true;
    }

then I run a Scan the organization folder, but don't see any mention to the tags. What's up with that? Is there something else missing along the way?

Examining org/repo

  Checking branches...

  Getting remote branches...

    Checking branch feature/publishers
      ‘Jenkinsfile’ found
    Met criteria
No changes detected: feature/publishers (still at a29373c2e692bf549f7ff114e4be6ed82f7d056d)

    Checking branch master
      ‘Jenkinsfile’ found
    Met criteria
No changes detected: master (still at a9bc55ee5d6e82111f6ca70ea6168da9289ddd12)

    Checking branch test
      ‘Jenkinsfile’ found
    Met criteria
No changes detected: test (still at b224b0276df138020efed0d1545f97c4bff294cd)

  3 branches were processed

  Checking pull-requests...

  Getting remote pull requests...

  0 pull requests were processed

Finished examining org/repo




On Thursday, 7 September 2017 11:43:41 UTC+2, Stephen Connolly wrote:


On 6 September 2017 at 23:24, Stephen Connolly <[hidden email]> wrote:

On Thu 7 Sep 2017 at 07:22, Stephen Connolly <[hidden email]> wrote:
You are waiting on <a href="https://github.com/jenkinsci/github-branch-source-plugin/pull/158" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fjenkinsci%2Fgithub-branch-source-plugin%2Fpull%2F158\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHHhD34lpD2GN6sIudMzReSkRphog&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fjenkinsci%2Fgithub-branch-source-plugin%2Fpull%2F158\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHHhD34lpD2GN6sIudMzReSkRphog&#39;;return true;">https://github.com/jenkinsci/github-branch-source-plugin/pull/158 to be merged then.

You could build the plugin with the PR merged and do some testing to help give better confidence for releasing that PR


On Thu 7 Sep 2017 at 00:43, <[hidden email]> wrote:
Oh, to clarify, we're using the "github branch source" plugin and I have already confirmed that github is correctly firing the webhook.

Hmmm the event side of that PR may need updating... 

Would be really good to see if tags get created by events or if they only show on an index with the current PR

Had a look at the code, tag events were not being handled, so I pushed <a href="https://github.com/jenkinsci/github-branch-source-plugin/pull/158/commits/51fc6efbfed92f541032ed672be2ee9d9ac2e398" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fjenkinsci%2Fgithub-branch-source-plugin%2Fpull%2F158%2Fcommits%2F51fc6efbfed92f541032ed672be2ee9d9ac2e398\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGVGi8ocXpAU_vbJ0RivSgLGCTyVg&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fjenkinsci%2Fgithub-branch-source-plugin%2Fpull%2F158%2Fcommits%2F51fc6efbfed92f541032ed672be2ee9d9ac2e398\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGVGi8ocXpAU_vbJ0RivSgLGCTyVg&#39;;return true;">https://github.com/jenkinsci/github-branch-source-plugin/pull/158/commits/51fc6efbfed92f541032ed672be2ee9d9ac2e398 which should provide event support for tags

Now if you want tags to build automatically, then you will need to write an extension plugin for branch-api that provides an implementation of <a href="https://github.com/jenkinsci/branch-api-plugin/blob/master/src/main/java/jenkins/branch/BranchBuildStrategy.java" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fjenkinsci%2Fbranch-api-plugin%2Fblob%2Fmaster%2Fsrc%2Fmain%2Fjava%2Fjenkins%2Fbranch%2FBranchBuildStrategy.java\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFunIBM-mYtQMWcZSgkfXTevEYRgQ&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fjenkinsci%2Fbranch-api-plugin%2Fblob%2Fmaster%2Fsrc%2Fmain%2Fjava%2Fjenkins%2Fbranch%2FBranchBuildStrategy.java\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFunIBM-mYtQMWcZSgkfXTevEYRgQ&#39;;return true;">https://github.com/jenkinsci/branch-api-plugin/blob/master/src/main/java/jenkins/branch/BranchBuildStrategy.java (one there is at least one BranchBuildStrategy extension defined in your Jenkins then the BranchSource should allow you to add the strategies: <a href="https://github.com/jenkinsci/branch-api-plugin/blob/master/src/main/resources/jenkins/branch/BranchSource/config.jelly#L45" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fjenkinsci%2Fbranch-api-plugin%2Fblob%2Fmaster%2Fsrc%2Fmain%2Fresources%2Fjenkins%2Fbranch%2FBranchSource%2Fconfig.jelly%23L45\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNF-phE6_Y4cqAhyRJ58TLQkHQrbJA&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fjenkinsci%2Fbranch-api-plugin%2Fblob%2Fmaster%2Fsrc%2Fmain%2Fresources%2Fjenkins%2Fbranch%2FBranchSource%2Fconfig.jelly%23L45\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNF-phE6_Y4cqAhyRJ58TLQkHQrbJA&#39;;return true;">https://github.com/jenkinsci/branch-api-plugin/blob/master/src/main/resources/jenkins/branch/BranchSource/config.jelly#L45 Note though, <a href="https://github.com/jenkinsci/branch-api-plugin/blob/22c8d12a5ad3b523042343bb769b15affb11d1a6/src/main/java/jenkins/branch/MultiBranchProject.java#L2162-L2173" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fjenkinsci%2Fbranch-api-plugin%2Fblob%2F22c8d12a5ad3b523042343bb769b15affb11d1a6%2Fsrc%2Fmain%2Fjava%2Fjenkins%2Fbranch%2FMultiBranchProject.java%23L2162-L2173\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNF-jaSKFkK13o-4YSNWOzwwaDvcNA&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fjenkinsci%2Fbranch-api-plugin%2Fblob%2F22c8d12a5ad3b523042343bb769b15affb11d1a6%2Fsrc%2Fmain%2Fjava%2Fjenkins%2Fbranch%2FMultiBranchProject.java%23L2162-L2173\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNF-jaSKFkK13o-4YSNWOzwwaDvcNA&#39;;return true;">https://github.com/jenkinsci/branch-api-plugin/blob/22c8d12a5ad3b523042343bb769b15affb11d1a6/src/main/java/jenkins/branch/MultiBranchProject.java#L2162-L2173 so if you configure a source with one or more BranchBuildStrategy instances then that source will stop using the default behaviour of auto-build anything that is not a tag, so you might need more than one strategy to provide the flexibility you want
 



On Wednesday, September 6, 2017 at 4:38:05 PM UTC-7, [hidden email] wrote:
One of the fundamental concepts in CI/CD is "build once". So... we build for every commit and test. Code which we want to promote, we merge and then test again. If tests pass, we tag it with a release number in git (v3.2 for example) and push that. I expect jenkins to fire a build. Our jenkinsfile will then do a docker pull and discover it's already built, apply the new tag and docker push.

But it sounds like this workflow is fundamentally not possible with Jenkins. Is that correct?

A

On Friday, July 14, 2017 at 9:00:10 AM UTC-7, Mark Waite wrote:


On Friday, July 14, 2017 at 7:56:00 AM UTC-8, Samuel Henrique wrote:
Hello,

I'm trying to make jenkins trigger a build whenever a new tag is pushed to my git repo.

I already made it to trigger builds when a tag pointing to a new commit is pushed, by setting:

refspec: +refs/tags/*:refs/remotes/origin/tags/*
branch specifier: **

The problem is that the builds are not triggered when i tag some commit that already has another tag, even if its an annotated tag.

The use case is as follows:

1)We need devs to be able to deploy our webapp by tagging releases on github (mostly in other branches than master), like tag: v1.0.0 (the previous tag was v0.9.9).
2)We need to be able to rollback deploys, by tagging again previous releases (rollbacks will be always tagging commits on master), like tag: v0.9.9-rollback [ponting to the same commit as v0.9.9).
3)We also need to follow some process that would allow fresh servers to retrieve the same deployed release as the other servers (dealing with autoscalling/dynamic inventory)

The 3rd item is easily solvable by configuring capistrano to self-deploy the last tag (sorting tags by taggerdate) on server startup (so new machines will fetch rollbacks too).

The 1st item is already good, as jenkins always trigger a build when a tag ponting to a new commit is pushed.

My problem is with rollbacks (2nd item), jenkins will receive the git hook, poll the repository but won't trigger the build, it detects the new tag but it acts as it already built that.

I've searched online and from what i read, i think the git plugin is checking the hash the tag points to, not the hash from the tag itself, thus it doesn't detect a change. Can somebody confirm if i'm right, or if the problem is is another plugin?


That is correct.  The git plugin assumes that once it has built a commit, then it does not need to build it again.

There are alternatives that may allow you to force a build of an already built commit.  For instance, you could parameterize a build to take the tag of the commit to build as an argument, then invoke it with a POST from the "curl" command to build that specific tag.  That isn't as elegant as the webhook technique that you're trying to use, since it requires that you create something that detects the creation of a new tag, then when the new tag is detected, it calls that curl command.

Mark Waite
 
Any help is highly appreciated.

--
You received this message because you are subscribed to the Google Groups "Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-use...@googlegroups.com.
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/jenkinsci-users/2add8404-567b-400d-baa2-2562cebe867f%40googlegroups.com?utm_medium=email&amp;utm_source=footer" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/msgid/jenkinsci-users/2add8404-567b-400d-baa2-2562cebe867f%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/msgid/jenkinsci-users/2add8404-567b-400d-baa2-2562cebe867f%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;">https://groups.google.com/d/msgid/jenkinsci-users/2add8404-567b-400d-baa2-2562cebe867f%40googlegroups.com.
For more options, visit <a href="https://groups.google.com/d/optout" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;">https://groups.google.com/d/optout.
--
Sent from my phone
--
Sent from my phone

--
You received this message because you are subscribed to the Google Groups "Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="javascript:" target="_blank" gdf-obfuscated-mailto="uFDRQVphAwAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">jenkinsci-use...@googlegroups.com.
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/jenkinsci-users/d90508e3-95e4-42a9-99be-70d75ae54da0%40googlegroups.com?utm_medium=email&amp;utm_source=footer" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/d/msgid/jenkinsci-users/d90508e3-95e4-42a9-99be-70d75ae54da0%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/msgid/jenkinsci-users/d90508e3-95e4-42a9-99be-70d75ae54da0%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;">https://groups.google.com/d/msgid/jenkinsci-users/d90508e3-95e4-42a9-99be-70d75ae54da0%40googlegroups.com.

For more options, visit <a href="https://groups.google.com/d/optout" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;">https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/8f54fdd7-c856-4c8a-948c-12b71418c599%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: [hard] problem building github tags

Knurek
In reply to this post by stephenconnolly
hmm, I checked out your branch:
https://github.com/stephenc/github-branch-source-plugin/tree/jenkins-34395
compiled and installed: 2.2.5-SNAPSHOT (private-e98acfa4-root)
but still not seeing any tags built



On Wednesday, 1 November 2017 16:54:22 UTC+1, Stephen Connolly wrote:
2.2.4 does not have discovery of tags merged yet

On 1 November 2017 at 08:15, <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="uFDRQVphAwAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">j.kn...@...> wrote:
I've got version 2.2.4 of GitHub Branch Source Plugin installed, and
compiled, installed, and configured my organization folder to use <a href="https://github.com/AngryBytes/jenkins-build-everything-strategy-plugin" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2FAngryBytes%2Fjenkins-build-everything-strategy-plugin\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFZ4N0SLh8qcULAx1-Awsiz6i59vw&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2FAngryBytes%2Fjenkins-build-everything-strategy-plugin\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFZ4N0SLh8qcULAx1-Awsiz6i59vw&#39;;return true;">https://github.com/AngryBytes/jenkins-build-everything-strategy-plugin
which uses:
     @Override
    public boolean isAutomaticBuild(SCMSource source, SCMHead head) {
        return true;
    }

then I run a Scan the organization folder, but don't see any mention to the tags. What's up with that? Is there something else missing along the way?

Examining org/repo

  Checking branches...

  Getting remote branches...

    Checking branch feature/publishers
      ‘Jenkinsfile’ found
    Met criteria
No changes detected: feature/publishers (still at a29373c2e692bf549f7ff114e4be6ed82f7d056d)

    Checking branch master
      ‘Jenkinsfile’ found
    Met criteria
No changes detected: master (still at a9bc55ee5d6e82111f6ca70ea6168da9289ddd12)

    Checking branch test
      ‘Jenkinsfile’ found
    Met criteria
No changes detected: test (still at b224b0276df138020efed0d1545f97c4bff294cd)

  3 branches were processed

  Checking pull-requests...

  Getting remote pull requests...

  0 pull requests were processed

Finished examining org/repo




On Thursday, 7 September 2017 11:43:41 UTC+2, Stephen Connolly wrote:


On 6 September 2017 at 23:24, Stephen Connolly <[hidden email]> wrote:

On Thu 7 Sep 2017 at 07:22, Stephen Connolly <[hidden email]> wrote:
You are waiting on <a href="https://github.com/jenkinsci/github-branch-source-plugin/pull/158" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fjenkinsci%2Fgithub-branch-source-plugin%2Fpull%2F158\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHHhD34lpD2GN6sIudMzReSkRphog&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fjenkinsci%2Fgithub-branch-source-plugin%2Fpull%2F158\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHHhD34lpD2GN6sIudMzReSkRphog&#39;;return true;">https://github.com/jenkinsci/github-branch-source-plugin/pull/158 to be merged then.

You could build the plugin with the PR merged and do some testing to help give better confidence for releasing that PR


On Thu 7 Sep 2017 at 00:43, <[hidden email]> wrote:
Oh, to clarify, we're using the "github branch source" plugin and I have already confirmed that github is correctly firing the webhook.

Hmmm the event side of that PR may need updating... 

Would be really good to see if tags get created by events or if they only show on an index with the current PR

Had a look at the code, tag events were not being handled, so I pushed <a href="https://github.com/jenkinsci/github-branch-source-plugin/pull/158/commits/51fc6efbfed92f541032ed672be2ee9d9ac2e398" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fjenkinsci%2Fgithub-branch-source-plugin%2Fpull%2F158%2Fcommits%2F51fc6efbfed92f541032ed672be2ee9d9ac2e398\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGVGi8ocXpAU_vbJ0RivSgLGCTyVg&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fjenkinsci%2Fgithub-branch-source-plugin%2Fpull%2F158%2Fcommits%2F51fc6efbfed92f541032ed672be2ee9d9ac2e398\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGVGi8ocXpAU_vbJ0RivSgLGCTyVg&#39;;return true;">https://github.com/jenkinsci/github-branch-source-plugin/pull/158/commits/51fc6efbfed92f541032ed672be2ee9d9ac2e398 which should provide event support for tags

Now if you want tags to build automatically, then you will need to write an extension plugin for branch-api that provides an implementation of <a href="https://github.com/jenkinsci/branch-api-plugin/blob/master/src/main/java/jenkins/branch/BranchBuildStrategy.java" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fjenkinsci%2Fbranch-api-plugin%2Fblob%2Fmaster%2Fsrc%2Fmain%2Fjava%2Fjenkins%2Fbranch%2FBranchBuildStrategy.java\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFunIBM-mYtQMWcZSgkfXTevEYRgQ&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fjenkinsci%2Fbranch-api-plugin%2Fblob%2Fmaster%2Fsrc%2Fmain%2Fjava%2Fjenkins%2Fbranch%2FBranchBuildStrategy.java\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFunIBM-mYtQMWcZSgkfXTevEYRgQ&#39;;return true;">https://github.com/jenkinsci/branch-api-plugin/blob/master/src/main/java/jenkins/branch/BranchBuildStrategy.java (one there is at least one BranchBuildStrategy extension defined in your Jenkins then the BranchSource should allow you to add the strategies: <a href="https://github.com/jenkinsci/branch-api-plugin/blob/master/src/main/resources/jenkins/branch/BranchSource/config.jelly#L45" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fjenkinsci%2Fbranch-api-plugin%2Fblob%2Fmaster%2Fsrc%2Fmain%2Fresources%2Fjenkins%2Fbranch%2FBranchSource%2Fconfig.jelly%23L45\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNF-phE6_Y4cqAhyRJ58TLQkHQrbJA&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fjenkinsci%2Fbranch-api-plugin%2Fblob%2Fmaster%2Fsrc%2Fmain%2Fresources%2Fjenkins%2Fbranch%2FBranchSource%2Fconfig.jelly%23L45\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNF-phE6_Y4cqAhyRJ58TLQkHQrbJA&#39;;return true;">https://github.com/jenkinsci/branch-api-plugin/blob/master/src/main/resources/jenkins/branch/BranchSource/config.jelly#L45 Note though, <a href="https://github.com/jenkinsci/branch-api-plugin/blob/22c8d12a5ad3b523042343bb769b15affb11d1a6/src/main/java/jenkins/branch/MultiBranchProject.java#L2162-L2173" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fjenkinsci%2Fbranch-api-plugin%2Fblob%2F22c8d12a5ad3b523042343bb769b15affb11d1a6%2Fsrc%2Fmain%2Fjava%2Fjenkins%2Fbranch%2FMultiBranchProject.java%23L2162-L2173\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNF-jaSKFkK13o-4YSNWOzwwaDvcNA&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fjenkinsci%2Fbranch-api-plugin%2Fblob%2F22c8d12a5ad3b523042343bb769b15affb11d1a6%2Fsrc%2Fmain%2Fjava%2Fjenkins%2Fbranch%2FMultiBranchProject.java%23L2162-L2173\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNF-jaSKFkK13o-4YSNWOzwwaDvcNA&#39;;return true;">https://github.com/jenkinsci/branch-api-plugin/blob/22c8d12a5ad3b523042343bb769b15affb11d1a6/src/main/java/jenkins/branch/MultiBranchProject.java#L2162-L2173 so if you configure a source with one or more BranchBuildStrategy instances then that source will stop using the default behaviour of auto-build anything that is not a tag, so you might need more than one strategy to provide the flexibility you want
 



On Wednesday, September 6, 2017 at 4:38:05 PM UTC-7, [hidden email] wrote:
One of the fundamental concepts in CI/CD is "build once". So... we build for every commit and test. Code which we want to promote, we merge and then test again. If tests pass, we tag it with a release number in git (v3.2 for example) and push that. I expect jenkins to fire a build. Our jenkinsfile will then do a docker pull and discover it's already built, apply the new tag and docker push.

But it sounds like this workflow is fundamentally not possible with Jenkins. Is that correct?

A

On Friday, July 14, 2017 at 9:00:10 AM UTC-7, Mark Waite wrote:


On Friday, July 14, 2017 at 7:56:00 AM UTC-8, Samuel Henrique wrote:
Hello,

I'm trying to make jenkins trigger a build whenever a new tag is pushed to my git repo.

I already made it to trigger builds when a tag pointing to a new commit is pushed, by setting:

refspec: +refs/tags/*:refs/remotes/origin/tags/*
branch specifier: **

The problem is that the builds are not triggered when i tag some commit that already has another tag, even if its an annotated tag.

The use case is as follows:

1)We need devs to be able to deploy our webapp by tagging releases on github (mostly in other branches than master), like tag: v1.0.0 (the previous tag was v0.9.9).
2)We need to be able to rollback deploys, by tagging again previous releases (rollbacks will be always tagging commits on master), like tag: v0.9.9-rollback [ponting to the same commit as v0.9.9).
3)We also need to follow some process that would allow fresh servers to retrieve the same deployed release as the other servers (dealing with autoscalling/dynamic inventory)

The 3rd item is easily solvable by configuring capistrano to self-deploy the last tag (sorting tags by taggerdate) on server startup (so new machines will fetch rollbacks too).

The 1st item is already good, as jenkins always trigger a build when a tag ponting to a new commit is pushed.

My problem is with rollbacks (2nd item), jenkins will receive the git hook, poll the repository but won't trigger the build, it detects the new tag but it acts as it already built that.

I've searched online and from what i read, i think the git plugin is checking the hash the tag points to, not the hash from the tag itself, thus it doesn't detect a change. Can somebody confirm if i'm right, or if the problem is is another plugin?


That is correct.  The git plugin assumes that once it has built a commit, then it does not need to build it again.

There are alternatives that may allow you to force a build of an already built commit.  For instance, you could parameterize a build to take the tag of the commit to build as an argument, then invoke it with a POST from the "curl" command to build that specific tag.  That isn't as elegant as the webhook technique that you're trying to use, since it requires that you create something that detects the creation of a new tag, then when the new tag is detected, it calls that curl command.

Mark Waite
 
Any help is highly appreciated.

--
You received this message because you are subscribed to the Google Groups "Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-use...@googlegroups.com.
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/jenkinsci-users/2add8404-567b-400d-baa2-2562cebe867f%40googlegroups.com?utm_medium=email&amp;utm_source=footer" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/msgid/jenkinsci-users/2add8404-567b-400d-baa2-2562cebe867f%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/msgid/jenkinsci-users/2add8404-567b-400d-baa2-2562cebe867f%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;">https://groups.google.com/d/msgid/jenkinsci-users/2add8404-567b-400d-baa2-2562cebe867f%40googlegroups.com.
For more options, visit <a href="https://groups.google.com/d/optout" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;">https://groups.google.com/d/optout.
--
Sent from my phone
--
Sent from my phone

--
You received this message because you are subscribed to the Google Groups "Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="javascript:" target="_blank" gdf-obfuscated-mailto="uFDRQVphAwAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">jenkinsci-use...@googlegroups.com.
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/jenkinsci-users/d90508e3-95e4-42a9-99be-70d75ae54da0%40googlegroups.com?utm_medium=email&amp;utm_source=footer" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/d/msgid/jenkinsci-users/d90508e3-95e4-42a9-99be-70d75ae54da0%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/msgid/jenkinsci-users/d90508e3-95e4-42a9-99be-70d75ae54da0%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;">https://groups.google.com/d/msgid/jenkinsci-users/d90508e3-95e4-42a9-99be-70d75ae54da0%40googlegroups.com.

For more options, visit <a href="https://groups.google.com/d/optout" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;">https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/9c013866-d7e8-4d64-b55b-82359613a995%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: [hard] problem building github tags

wayne
Can anyone help me please as that branch is gone, I have Jenkins 2.73.3 installed but how do I use this feature as it says available from 2.30?  

I've spent much longer on trying to get this to work than I thought I would, for reference I've been over these before finally finding this forum post: 

http://johndstein-blog.logdown.com/posts/428667
https://github.com/membrane/jenkins-git-tag-builder
'albertskis' answer: https://stackoverflow.com/questions/29742847/jenkins-trigger-build-if-new-tag-is-released
https://github.com/jenkinsci/github-branch-source-plugin/pull/158/
https://issues.jenkins-ci.org/browse/JENKINS-34395

thanks
Wayne
On Wednesday, November 1, 2017 at 4:40:39 PM UTC, [hidden email] wrote:
hmm, I checked out your branch:
<a href="https://github.com/stephenc/github-branch-source-plugin/tree/jenkins-34395" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fstephenc%2Fgithub-branch-source-plugin%2Ftree%2Fjenkins-34395\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEer42gBMjdv0xiFPI2wvhJO5v5Cg&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fstephenc%2Fgithub-branch-source-plugin%2Ftree%2Fjenkins-34395\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEer42gBMjdv0xiFPI2wvhJO5v5Cg&#39;;return true;">https://github.com/stephenc/github-branch-source-plugin/tree/jenkins-34395
compiled and installed: 2.2.5-SNAPSHOT (private-e98acfa4-root)
but still not seeing any tags built



On Wednesday, 1 November 2017 16:54:22 UTC+1, Stephen Connolly wrote:
2.2.4 does not have discovery of tags merged yet

On 1 November 2017 at 08:15, <[hidden email]> wrote:
I've got version 2.2.4 of GitHub Branch Source Plugin installed, and
compiled, installed, and configured my organization folder to use <a href="https://github.com/AngryBytes/jenkins-build-everything-strategy-plugin" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2FAngryBytes%2Fjenkins-build-everything-strategy-plugin\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFZ4N0SLh8qcULAx1-Awsiz6i59vw&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2FAngryBytes%2Fjenkins-build-everything-strategy-plugin\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFZ4N0SLh8qcULAx1-Awsiz6i59vw&#39;;return true;">https://github.com/AngryBytes/jenkins-build-everything-strategy-plugin
which uses:
     @Override
    public boolean isAutomaticBuild(SCMSource source, SCMHead head) {
        return true;
    }

then I run a Scan the organization folder, but don't see any mention to the tags. What's up with that? Is there something else missing along the way?

Examining org/repo

  Checking branches...

  Getting remote branches...

    Checking branch feature/publishers
      ‘Jenkinsfile’ found
    Met criteria
No changes detected: feature/publishers (still at a29373c2e692bf549f7ff114e4be6ed82f7d056d)

    Checking branch master
      ‘Jenkinsfile’ found
    Met criteria
No changes detected: master (still at a9bc55ee5d6e82111f6ca70ea6168da9289ddd12)

    Checking branch test
      ‘Jenkinsfile’ found
    Met criteria
No changes detected: test (still at b224b0276df138020efed0d1545f97c4bff294cd)

  3 branches were processed

  Checking pull-requests...

  Getting remote pull requests...

  0 pull requests were processed

Finished examining org/repo




On Thursday, 7 September 2017 11:43:41 UTC+2, Stephen Connolly wrote:


On 6 September 2017 at 23:24, Stephen Connolly <[hidden email]> wrote:

On Thu 7 Sep 2017 at 07:22, Stephen Connolly <[hidden email]> wrote:
You are waiting on <a href="https://github.com/jenkinsci/github-branch-source-plugin/pull/158" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fjenkinsci%2Fgithub-branch-source-plugin%2Fpull%2F158\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHHhD34lpD2GN6sIudMzReSkRphog&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fjenkinsci%2Fgithub-branch-source-plugin%2Fpull%2F158\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHHhD34lpD2GN6sIudMzReSkRphog&#39;;return true;">https://github.com/jenkinsci/github-branch-source-plugin/pull/158 to be merged then.

You could build the plugin with the PR merged and do some testing to help give better confidence for releasing that PR


On Thu 7 Sep 2017 at 00:43, <[hidden email]> wrote:
Oh, to clarify, we're using the "github branch source" plugin and I have already confirmed that github is correctly firing the webhook.

Hmmm the event side of that PR may need updating... 

Would be really good to see if tags get created by events or if they only show on an index with the current PR

Had a look at the code, tag events were not being handled, so I pushed <a href="https://github.com/jenkinsci/github-branch-source-plugin/pull/158/commits/51fc6efbfed92f541032ed672be2ee9d9ac2e398" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fjenkinsci%2Fgithub-branch-source-plugin%2Fpull%2F158%2Fcommits%2F51fc6efbfed92f541032ed672be2ee9d9ac2e398\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGVGi8ocXpAU_vbJ0RivSgLGCTyVg&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fjenkinsci%2Fgithub-branch-source-plugin%2Fpull%2F158%2Fcommits%2F51fc6efbfed92f541032ed672be2ee9d9ac2e398\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGVGi8ocXpAU_vbJ0RivSgLGCTyVg&#39;;return true;">https://github.com/jenkinsci/github-branch-source-plugin/pull/158/commits/51fc6efbfed92f541032ed672be2ee9d9ac2e398 which should provide event support for tags

Now if you want tags to build automatically, then you will need to write an extension plugin for branch-api that provides an implementation of <a href="https://github.com/jenkinsci/branch-api-plugin/blob/master/src/main/java/jenkins/branch/BranchBuildStrategy.java" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fjenkinsci%2Fbranch-api-plugin%2Fblob%2Fmaster%2Fsrc%2Fmain%2Fjava%2Fjenkins%2Fbranch%2FBranchBuildStrategy.java\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFunIBM-mYtQMWcZSgkfXTevEYRgQ&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fjenkinsci%2Fbranch-api-plugin%2Fblob%2Fmaster%2Fsrc%2Fmain%2Fjava%2Fjenkins%2Fbranch%2FBranchBuildStrategy.java\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFunIBM-mYtQMWcZSgkfXTevEYRgQ&#39;;return true;">https://github.com/jenkinsci/branch-api-plugin/blob/master/src/main/java/jenkins/branch/BranchBuildStrategy.java (one there is at least one BranchBuildStrategy extension defined in your Jenkins then the BranchSource should allow you to add the strategies: <a href="https://github.com/jenkinsci/branch-api-plugin/blob/master/src/main/resources/jenkins/branch/BranchSource/config.jelly#L45" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fjenkinsci%2Fbranch-api-plugin%2Fblob%2Fmaster%2Fsrc%2Fmain%2Fresources%2Fjenkins%2Fbranch%2FBranchSource%2Fconfig.jelly%23L45\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNF-phE6_Y4cqAhyRJ58TLQkHQrbJA&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fjenkinsci%2Fbranch-api-plugin%2Fblob%2Fmaster%2Fsrc%2Fmain%2Fresources%2Fjenkins%2Fbranch%2FBranchSource%2Fconfig.jelly%23L45\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNF-phE6_Y4cqAhyRJ58TLQkHQrbJA&#39;;return true;">https://github.com/jenkinsci/branch-api-plugin/blob/master/src/main/resources/jenkins/branch/BranchSource/config.jelly#L45 Note though, <a href="https://github.com/jenkinsci/branch-api-plugin/blob/22c8d12a5ad3b523042343bb769b15affb11d1a6/src/main/java/jenkins/branch/MultiBranchProject.java#L2162-L2173" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fjenkinsci%2Fbranch-api-plugin%2Fblob%2F22c8d12a5ad3b523042343bb769b15affb11d1a6%2Fsrc%2Fmain%2Fjava%2Fjenkins%2Fbranch%2FMultiBranchProject.java%23L2162-L2173\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNF-jaSKFkK13o-4YSNWOzwwaDvcNA&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fjenkinsci%2Fbranch-api-plugin%2Fblob%2F22c8d12a5ad3b523042343bb769b15affb11d1a6%2Fsrc%2Fmain%2Fjava%2Fjenkins%2Fbranch%2FMultiBranchProject.java%23L2162-L2173\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNF-jaSKFkK13o-4YSNWOzwwaDvcNA&#39;;return true;">https://github.com/jenkinsci/branch-api-plugin/blob/22c8d12a5ad3b523042343bb769b15affb11d1a6/src/main/java/jenkins/branch/MultiBranchProject.java#L2162-L2173 so if you configure a source with one or more BranchBuildStrategy instances then that source will stop using the default behaviour of auto-build anything that is not a tag, so you might need more than one strategy to provide the flexibility you want
 



On Wednesday, September 6, 2017 at 4:38:05 PM UTC-7, [hidden email] wrote:
One of the fundamental concepts in CI/CD is "build once". So... we build for every commit and test. Code which we want to promote, we merge and then test again. If tests pass, we tag it with a release number in git (v3.2 for example) and push that. I expect jenkins to fire a build. Our jenkinsfile will then do a docker pull and discover it's already built, apply the new tag and docker push.

But it sounds like this workflow is fundamentally not possible with Jenkins. Is that correct?

A

On Friday, July 14, 2017 at 9:00:10 AM UTC-7, Mark Waite wrote:


On Friday, July 14, 2017 at 7:56:00 AM UTC-8, Samuel Henrique wrote:
Hello,

I'm trying to make jenkins trigger a build whenever a new tag is pushed to my git repo.

I already made it to trigger builds when a tag pointing to a new commit is pushed, by setting:

refspec: +refs/tags/*:refs/remotes/origin/tags/*
branch specifier: **

The problem is that the builds are not triggered when i tag some commit that already has another tag, even if its an annotated tag.

The use case is as follows:

1)We need devs to be able to deploy our webapp by tagging releases on github (mostly in other branches than master), like tag: v1.0.0 (the previous tag was v0.9.9).
2)We need to be able to rollback deploys, by tagging again previous releases (rollbacks will be always tagging commits on master), like tag: v0.9.9-rollback [ponting to the same commit as v0.9.9).
3)We also need to follow some process that would allow fresh servers to retrieve the same deployed release as the other servers (dealing with autoscalling/dynamic inventory)

The 3rd item is easily solvable by configuring capistrano to self-deploy the last tag (sorting tags by taggerdate) on server startup (so new machines will fetch rollbacks too).

The 1st item is already good, as jenkins always trigger a build when a tag ponting to a new commit is pushed.

My problem is with rollbacks (2nd item), jenkins will receive the git hook, poll the repository but won't trigger the build, it detects the new tag but it acts as it already built that.

I've searched online and from what i read, i think the git plugin is checking the hash the tag points to, not the hash from the tag itself, thus it doesn't detect a change. Can somebody confirm if i'm right, or if the problem is is another plugin?


That is correct.  The git plugin assumes that once it has built a commit, then it does not need to build it again.

There are alternatives that may allow you to force a build of an already built commit.  For instance, you could parameterize a build to take the tag of the commit to build as an argument, then invoke it with a POST from the "curl" command to build that specific tag.  That isn't as elegant as the webhook technique that you're trying to use, since it requires that you create something that detects the creation of a new tag, then when the new tag is detected, it calls that curl command.

Mark Waite
 
Any help is highly appreciated.

--
You received this message because you are subscribed to the Google Groups "Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-use...@googlegroups.com.
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/jenkinsci-users/2add8404-567b-400d-baa2-2562cebe867f%40googlegroups.com?utm_medium=email&amp;utm_source=footer" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/msgid/jenkinsci-users/2add8404-567b-400d-baa2-2562cebe867f%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/msgid/jenkinsci-users/2add8404-567b-400d-baa2-2562cebe867f%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;">https://groups.google.com/d/msgid/jenkinsci-users/2add8404-567b-400d-baa2-2562cebe867f%40googlegroups.com.
For more options, visit <a href="https://groups.google.com/d/optout" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;">https://groups.google.com/d/optout.
--
Sent from my phone
--
Sent from my phone

--
You received this message because you are subscribed to the Google Groups "Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-use...@googlegroups.com.
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/jenkinsci-users/d90508e3-95e4-42a9-99be-70d75ae54da0%40googlegroups.com?utm_medium=email&amp;utm_source=footer" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/msgid/jenkinsci-users/d90508e3-95e4-42a9-99be-70d75ae54da0%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/msgid/jenkinsci-users/d90508e3-95e4-42a9-99be-70d75ae54da0%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;">https://groups.google.com/d/msgid/jenkinsci-users/d90508e3-95e4-42a9-99be-70d75ae54da0%40googlegroups.com.

For more options, visit <a href="https://groups.google.com/d/optout" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;">https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/cd55f068-bc62-427b-bf11-f5db1fa3e706%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.