-
Improvement
-
Resolution: Fixed
-
Major
-
Powered by SuggestiMate
Right now, using Jenkins to build releases is much harder than it should be. For every git repo I need to create two jobs. One to build branches and one to build tags. This is less than ideal, but works around the limitation that Jenkins hates git tags.
This works decently on the other git plugin, but completely impossible with this plugin. I think it would be fantastic to have this plugin build tags, and communicate with github about the build data.
- blocks
-
JENKINS-47250 Support running a pipeline using specific git tag in Blue Ocean
-
- Open
-
- is duplicated by
-
JENKINS-47481 git-plugin does not discover tags
-
- Closed
-
-
JENKINS-34176 Trigger when Github tag is pushed
-
- Resolved
-
-
JENKINS-34520 Can't use Jenkinsfile for build git tags
-
- Resolved
-
- is related to
-
JENKINS-46207 git-plugin should support tags in multibranch pipeline configurations
-
- Closed
-
-
JENKINS-47254 Support for building tags for Bitbucket Server/Cloud
-
- Closed
-
- relates to
-
JENKINS-37050 Pipeline Job Cannot Checkout Git Tag
-
- Closed
-
- links to
- mentioned in
-
Page Loading...
[JENKINS-34395] Support for building tags
There needs to be a way to build a "release". The two obvious patterns are:
- Somehow tell Jenkins this should be release and have it create a tag.
- Have Jenkins detect that a tag was set and build it as a release (like Travis does).
With pipeline (aka Jenkinsfile) situation is much more worse: you can't checkout specified tag (parameters don't pass to branch specifier as environment variables).
But pipeline script (Jenkinsfile) loaded immediatly after checkout and you can't checkout right commit via Jenkinsfile and restart pipeline. So, I did not find correct solution for this situation.
For workaround my problem I use patched git-plugin (https://github.com/jenkinsci/git-plugin/pull/408).
recena Sorry that I missed your initial reply.
Tag building is around releases. Under almost every workflow of git, when someone creates a tag they are marking some sort of release. It would be great if Jenkins would know about this common work flow and do a build. Added logic to the build script could be added to perform extra actions when building a release.
Github has a releases page for every project. Integration of builds on tags could populate the releases tab with information/assets from the build.
Jenkin's has the ability to create tags on every build (useless), and the ability to create a tag on a particular build. The latter is sometimes useful, however under almost all circumstances is not adequate.
We also need the ability to tell jenkins to build a tag. Impossible with multibranch pipeline.
Currently i need to have 3 jobs of same application:
1. multibranch pipeline
2. single branch pipeline
3. singlebranch pipeline with custom groovy script
1 is for building all commits in all branches (running tests etc).
2 is for building and pushing docker image to registry
3 is to notify 2 to build specific commit (by selecting a tag using input
node('go'){ stage 'Notify other job' def gitUrl = 'ssh://git@URL' git([url: gitUrl, branch: 'master', credentialsId: 'asdf']) sh('git show-ref --tags > tags') def tags = readFile('tags').trim() def userInput = input([ message: 'Please select git tag', parameters: [[$class: 'ChoiceParameterDefinition', choices: tags, description: '', name: 'Tag']]]) echo ("selected tag: "+userInput) def sha1 = userInput.split(' ')[0] echo ("selected sha1: "+ sha1) sh("curl \"http://URL:8080/git/notifyCommit?url="+gitUrl+"&sha1="+sha1+"\"") }
Why cant the multibranch job listen to notifyCommits with sha1?
Another solution is to fix the parameters so they could be sent to a multibranch pipeline script which then do git checkout based on tag.
+1 to this. Without tags support it's impossible to build projects that are using tags as release identifiers.
Another +1
Jenkins is not only a build automation tool, but also a deployment automation tool. If you want to have your deployments triggered off of tags, then this is a required feature.
+1
Was enjoying the pipeline functionality until I hit this issue. My requirements:
- one job per repository
- run job on every commit and tag
- if tagged build release
+1
EDIT:
We are moving actual jobs to pipeline. Our goal is build branches master, feature and PR but if the commit was pointed by a TAG (that means GIT_TAG or TAG_NAME exists and are not empty) than we do also an extra publish stage. Without tag variable we have to duplicate all job twice.
Please don't add "+1" to issues without further information — hit the "Vote for this issue" link in the top-right.
tl;dr: I don't think this is actually a problem in the github-branch-source plugin (but I'm not an expert).
This is hitting me too, for all the same reasons everyone is mentioning.
I spent some time looking at the assigned component, but I wasn't able to find anything that actually prevented it from running a build based on tags.
I cannot find anything in there that would short circuit it if the options are enabled. This would, I think, trigger a build. I don't think the problem exists in here, the hook parsing logic should result in everything being found. Whatever calls this `heads` method probably gets back a list of heads including the one from the tag push event.
Ohhh, maybe I'm wrong.
There's some assumptions that the ref always starts with `refs/heads` and is parsed out, so a tag will come in as `refs/heads/refs/tags/<tag>`. Obviously that isn't going to work. If the SCMProbe is the thing that actually triggers a build, this might be all that's needed to fix it.
We should probably have a thing that handles the tag bit so that way we can check out an actual tag, but it's probably not good to have tag parsing logic in more than one place. Still learning things and you might get a few more play-by-play comments
We are in a middle of a migration process to pipeline.
I must say this problem really block us
Yes please! It's like a missing piece of the larger puzzle and the whole github integration feels 90% complete without it.
There seems to be a history of Jenkins tag-hate. See JENKINS-27018, the resolution of which I find unacceptable.
PR issued. Sneak peak:
Code and progress available here
https://github.com/tanskann/github-branch-source-plugin
If you want to have TAG_NAME as pipeline env variable, you need to have this as well
niklas awesome sauce!
I did compile plugin with your changes (although it didn't pass PR tests on jenkinsci ) and it seems to work. I've managed to spot few issues if you are interested, and since you don't allow to create issues in your repo I will point them out below:
1 - Creating release does not refresh releases list (tab) but "Repository Events" is aware of new tag. Scan repository needs to be triggered manually.
2 - Creating release does not trigger job. Build needs to be scheduled manually.
3 - Scanning organization lists all repos with any tags, even there is no Jenkinsfile in repository.
Thanks for taking time and creating this PR - I was waiting for it for a long time.
Thank you for your feedback
- Good point.
For some reason webhooks are not working with the github enterprise that I'm using (API is returning Not found) butit should not be that hard to fix this. - I don't want to build tags automatically and branch-api-plugin by default does not either, but you could achieve that by creating a different build strategy https://github.com/jenkinsci/branch-api-plugin/commit/cf848af4addf33f0aae9c86149fc0cfd1fee5c82
- I see. There's probably a problem with workflow-multibranch-plugin plugin. I might look into it, but it's not that big of a problem, at least not for me.
Thanks niklas for working on this! Much appreciated.
One suggestion, re. enabling/disabling building releases: users will probably want control over which tags trigger a build.
It looks like the current version of the plugin already allows to specify a regular expression for which branch(es) should be built:
To let users control which tags they want to build, this could be extended to support full references instead of just the branch name, renaming "Branch names to build automatically" to "Refspecs to build automatically".
For example a value of
refs\/(heads|tags)\/.*
would build all branches and all tags. A value of
refs\/(heads\/.*|tags\/v.*)
would build all branches, and only tags starting with "v", which I assume is the most common setup for Github users.
As an alternative, if this is too much regex to expose to users, then have 2 separate fields: "Branch names to build automatically" and "Tag names to build automatically".
Anyway! Those are just suggestions. As long as the feature to enable building when tags are pushed is there I'll be a happy user .
I achieved tags building by modifying advanced setup for Git source:
This way I can build all the branches + tags, except alpha/beta tags.
Also when building from a tag, env.BRANCH_NAME gives you enough information if it's a tag or not in "tags/TAG_NAME_HERE" format.
The above works for multibranch pipeline projects, not for Github organisation folders.
FWIW, in his ongoing work on JENKINS-43507, I believe stephenconnolly has mentioned at some point there could be the ability to build from tags.
I have just had a partial success with triggering build on tag pushes.
What I've done is that basically I've set up a freestyle job using Git Plugin (and accompanying webhook on the repo side) with refspec and branch specifier fields set to
+refs/heads/*:refs/remotes/origin/* +refs/tags/*:refs/remotes/origin/tags/*
and
*/tags/*
respectively. This job does nothing but triggering an existing branch job in Multibranch project passing
${GIT_BRANCH}
(which contains the tag name) to it.
This way, in Jenkinsfile, I am able to check if a tag has been passed to the build.
This approach has one downside though – since I am triggering a build in existing branch job, Jenkinsfile containing the pipeline definition is fetched from the branch, not from the tag I am passing to it. Switching the repo's working copy to the appropriate tag is a part of Jenkinsfile.
Not sure how useful is this, but I think this is the best that can be achieved until this issue/improvement is resolved/introduced.
rmwpl You actually can use multi-branch pipeline type of job and configure refspec's there in order to be able to build from tags. But the downside of this approach is that there is no out of the box support for Github status update and you have to do it manually.
Github SCM way allows you to update the status for you, but in this case, you lose the possibility to build from tags.
vgaidarji, it seems to me that the whole idea behind this issues is that you cannot do this with Multibranch. For the record: specifying Refspec in Multibranch was the first thing that I've tried – with no avail.
But now that I've noticed niklas patched it, I'm inclined to give it a go.
niklas 's patch was forked about 6 months ago and its last release is 2.0.6
While the JenkinsSCI's project is now on its [2.2.3 release|https://github.com/jenkinsci/github-branch-source-plugin/releases].
Is it planned some day to have a gracefull tag handling whithin the "official" Github-Branch-Source-Plugin ?
Also require tag handling in bitbucket-branch-source-plugin as well!
Code changed in jenkins
User: Stephen Connolly
Path:
pom.xml
src/main/java/org/jenkinsci/plugins/github_branch_source/GitHubSCMFileSystem.java
src/main/java/org/jenkinsci/plugins/github_branch_source/GitHubSCMSource.java
src/main/java/org/jenkinsci/plugins/github_branch_source/GitHubSCMSourceRequest.java
src/main/java/org/jenkinsci/plugins/github_branch_source/GitHubTagSCMHead.java
src/main/java/org/jenkinsci/plugins/github_branch_source/TagDiscoveryTrait.java
src/main/resources/org/jenkinsci/plugins/github_branch_source/Messages.properties
src/main/resources/org/jenkinsci/plugins/github_branch_source/TagDiscoveryTrait/config.jelly
src/main/resources/org/jenkinsci/plugins/github_branch_source/TagDiscoveryTrait/help.html
http://jenkins-ci.org/commit/github-branch-source-plugin/e28cd4a846d73d45393d862c398ad90ae079f280
Log:
JENKINS-34395 Support for tag discovery
Code changed in jenkins
User: Stephen Connolly
Path:
src/main/java/org/jenkinsci/plugins/github_branch_source/GitHubSCMNavigator.java
src/main/java/org/jenkinsci/plugins/github_branch_source/GitHubSCMProbe.java
src/main/java/org/jenkinsci/plugins/github_branch_source/GitHubSCMSource.java
src/main/java/org/jenkinsci/plugins/github_branch_source/GitHubSCMSourceRequest.java
src/main/java/org/jenkinsci/plugins/github_branch_source/GitHubTagSCMHead.java
src/main/resources/org/jenkinsci/plugins/github_branch_source/Messages.properties
http://jenkins-ci.org/commit/github-branch-source-plugin/51415fa4887e726e81027dcd092b0400dbfced9f
Log:
JENKINS-34395 Updates based on manual testing
Code changed in jenkins
User: Stephen Connolly
Path:
src/main/java/org/jenkinsci/plugins/github_branch_source/GitHubSCMFileSystem.java
src/main/java/org/jenkinsci/plugins/github_branch_source/GitHubSCMProbe.java
src/main/java/org/jenkinsci/plugins/github_branch_source/GitHubSCMSource.java
src/test/resources/api/mappings/mapping-yolo-contents-64985.json
src/test/resources/api/mappings/mapping-yolo-contents-8rd37.json
src/test/resources/api/mappings/mapping-yolo-contents-DRrwo.json
src/test/resources/api/mappings/mapping-yolo-contents-pcVDb.json
http://jenkins-ci.org/commit/github-branch-source-plugin/d09440219c5a06260a2fe0e351cc86c7bf623444
Log:
JENKINS-34395 Found out that github-api plays fast and loose with the ref/ prefix
Code changed in jenkins
User: Stephen Connolly
Path:
src/main/java/org/jenkinsci/plugins/github_branch_source/GitHubSCMBuilder.java
src/main/java/org/jenkinsci/plugins/github_branch_source/GitHubSCMFile.java
src/main/java/org/jenkinsci/plugins/github_branch_source/GitHubSCMProbe.java
http://jenkins-ci.org/commit/github-branch-source-plugin/909ce6434f7d6ffc724f25dad02aba580a137a66
Log:
JENKINS-34395 Fix SCM build for tags
Code changed in jenkins
User: Stephen Connolly
Path:
src/main/java/org/jenkinsci/plugins/github_branch_source/GitHubSCMFile.java
src/main/java/org/jenkinsci/plugins/github_branch_source/GitHubSCMFileSystem.java
src/main/java/org/jenkinsci/plugins/github_branch_source/GitHubSCMSource.java
http://jenkins-ci.org/commit/github-branch-source-plugin/6f9ee583ae0ef854fd8541dce736b15ace9b55f8
Log:
JENKINS-34395 Ensure that lightweight checkout works for tags
Code changed in jenkins
User: Stephen Connolly
Path:
src/main/java/org/jenkinsci/plugins/github_branch_source/GitHubSCMFile.java
src/test/resources/api/mappings/mapping-yolo-contents-64985.json
src/test/resources/api/mappings/mapping-yolo-contents-8rd37.json
src/test/resources/api/mappings/mapping-yolo-contents-DRrwo.json
src/test/resources/api/mappings/mapping-yolo-contents-pcVDb.json
http://jenkins-ci.org/commit/github-branch-source-plugin/41e016f19b68d2ba618c669c462877f96c06ab3a
Log:
JENKINS-34395 Revert changes to test data and fix filesystem when using a hash rather than a ref
Code changed in jenkins
User: Stephen Connolly
Path:
src/main/java/org/jenkinsci/plugins/github_branch_source/GitHubSCMSourceRequest.java
src/main/java/org/jenkinsci/plugins/github_branch_source/PushGHEventSubscriber.java
http://jenkins-ci.org/commit/github-branch-source-plugin/51fc6efbfed92f541032ed672be2ee9d9ac2e398
Log:
JENKINS-34395 Properly handle push events for tags
Code changed in jenkins
User: Stephen Connolly
Path:
pom.xml
src/main/java/org/jenkinsci/plugins/github_branch_source/GitHubSCMSource.java
src/main/java/org/jenkinsci/plugins/github_branch_source/PullRequestAction.java
src/main/java/org/jenkinsci/plugins/github_branch_source/PullRequestGHEventSubscriber.java
http://jenkins-ci.org/commit/github-branch-source-plugin/4d47488b3116e2a605ff786353f4ac49319e9d69
Log:
JENKINS-34395 Update to 1.89 of github-api and guard against 404 in repos without any tags
Code changed in jenkins
User: Stephen Connolly
Path:
pom.xml
src/main/java/org/jenkinsci/plugins/github_branch_source/GitHubSCMFileSystem.java
src/main/java/org/jenkinsci/plugins/github_branch_source/GitHubSCMSource.java
src/main/java/org/jenkinsci/plugins/github_branch_source/GitHubTagSCMHead.java
src/main/java/org/jenkinsci/plugins/github_branch_source/PushGHEventSubscriber.java
src/main/java/org/jenkinsci/plugins/github_branch_source/TagDiscoveryTrait.java
src/test/java/org/jenkinsci/plugins/github_branch_source/TagDiscoveryTraitTest.java
http://jenkins-ci.org/commit/github-branch-source-plugin/e98acfa47bcd74c30423e5d24afff7556874022a
Log:
JENKINS-34395 Add some tests and update git dependency
Code changed in jenkins
User: Stephen Connolly
Path:
pom.xml
src/main/java/org/jenkinsci/plugins/github_branch_source/GitHubSCMFile.java
src/main/java/org/jenkinsci/plugins/github_branch_source/GitHubSCMFileSystem.java
src/main/java/org/jenkinsci/plugins/github_branch_source/GitHubSCMNavigator.java
src/main/java/org/jenkinsci/plugins/github_branch_source/GitHubSCMProbe.java
src/main/java/org/jenkinsci/plugins/github_branch_source/GitHubSCMSource.java
src/main/java/org/jenkinsci/plugins/github_branch_source/GitHubSCMSourceRequest.java
src/main/java/org/jenkinsci/plugins/github_branch_source/GitHubTagSCMHead.java
src/main/java/org/jenkinsci/plugins/github_branch_source/PullRequestAction.java
src/main/java/org/jenkinsci/plugins/github_branch_source/PullRequestGHEventSubscriber.java
src/main/java/org/jenkinsci/plugins/github_branch_source/PushGHEventSubscriber.java
src/main/java/org/jenkinsci/plugins/github_branch_source/TagDiscoveryTrait.java
src/main/resources/org/jenkinsci/plugins/github_branch_source/Messages.properties
src/main/resources/org/jenkinsci/plugins/github_branch_source/TagDiscoveryTrait/config.jelly
src/main/resources/org/jenkinsci/plugins/github_branch_source/TagDiscoveryTrait/help.html
src/test/java/org/jenkinsci/plugins/github_branch_source/TagDiscoveryTraitTest.java
http://jenkins-ci.org/commit/github-branch-source-plugin/2fc52660e0f095d7fe8b4f8e28eca95fc4bf50c2
Log:
Merge pull request #158 from stephenc/jenkins-34395
JENKINS-34395 Support for tag discovery
Compare: https://github.com/jenkinsci/github-branch-source-plugin/compare/e6e740de462a...2fc52660e0f0
georgemb Build tags? AFAIK tags are something static and this plugin is designed to build branches and PR, concepts that involve changes in our source code.