|
||||||||
|
This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira |
||||||||
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
This is actually possible (or rather was, it has regressed now) by setting up a job refering to refs/tags.
We have special "ReadyForIntegration" tags "RFI_whatever" that we use to kick some of our system integration pipelines in Jenkins:
Refspec: +refs/tags/RFI_foo_clients/:refs/remotes/origin/tags/RFI_foo_clients/
Branch specifier: /tags/RFI_foo_clients/*
that let the teams set tags like "RFI_foo_clients/R16/drop_1.0" and the integration-jobs distributes them according to the name-spaces in the tag.
If you trigg in refs/tags each annotated tag is it's own reference so each should build using the tag-reference, even if they dereference to the same commit. This used to work up until recently when only the first tag on a commit builds.
I'm attaching Jenkins-tag-trigger-bug.pdf with background-data from one of our jobs with four commits (of total 33) that has double tags on them, where two earlier works and the two later ones does not.
It may be due to the same cause with wildcard branches in JENKINS-20767 ?