On 4 January 2018 at 1:54:02am, Victor Martinez (victormar...@gmail.com) wrote:
I've not used that plugin in the past, but there are a couple of examples in the below test:
--
You received this message because you are subscribed to a topic in the Google Groups "Jenkins Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jenkinsci-users/4pUPjGuum44/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jenkinsci-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/8bda5313-74fa-48b4-954b-f1693f9e9983%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
stage("Build") { node { sh 'echo mvn' }}stage("Release") { release 'archive'}
I think that's a great idea. The main downsides I see are:
* the multibranch plugin (which I use already) is pretty flaky. I find it will sometimes reset all the branches to be enabled even though I try to disable old branches to get them out of the view
* if you create a lot of branches you end up with a huge number of workspaces and disk space which never goes away. In svn the solution to that is to create an 'archived' folder and move old branches/tags there. You can't do that in git though since it is more rigid in how it handles tags/branches.
* The UI gets cluttered in Jenkins
But I love the idea of a tag driving the release process and the version naming is embedded in the tag name itself.
On Thursday, 4 January 2018 16:11:14 UTC+11, Steven Foster wrote:I have been using the multibranch project's tag build functionality to achieve this. An environment variable is provided when running a tag build, so the pipeline can have a stage which checks for the presence of that variable.Using multibranch to build a single branch seems a little counter intuitive, but the branch api provides convenience in other areas and allows other branches to be added later with ease.The release process becomes something like:Push a tag -> Multibranch project detects tag and creates a job for that tag -> Manually run that tag job to perform a release (somewhat like a button on a build but a little more clear and structured imo)
--
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/13b94c91-3864-4a1e-acd8-f450bfb87078%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
* the multibranch plugin (which I use already) is pretty flaky. I find it will sometimes reset all the branches to be enabled even though I try to disable old branches to get them out of the viewYou shouldn’t be manually disabling branches. The disabled state should be controlled by the multibranch folder.Or could you explain what you are doing?
I’m using the old deprecated multibranch plugin (not the pipeline version) and as we finish with each branch I press the “disable project” button for that job. Which works until some upgrade of the plugin enables them all again. I don’t know how to control the disabled state in any other way. But perhaps that’s a feature of the pipeline version of this plugin.
(The enabled state should be updated to its “correct” value during a full scan)There should be no flakey (but there may be a bug whereby you can disable the branch by the UI... which we should fix)
I’ve always been able to press ‘disable project’ per branch and thought that was supposed to work like that.
* if you create a lot of branches you end up with a huge number of workspaces and disk space which never goes away. In svn the solution to that is to create an 'archived' folder and move old branches/tags there. You can't do that in git though since it is more rigid in how it handles tags/branches.Well one thing I do is have my pipeline empty the workspace at the end. This does mean a slower checkout, but I branch a lot, so I get a slower checkout anyway on a new branch.
* The UI gets cluttered in Jenkins
But I love the idea of a tag driving the release process and the version naming is embedded in the tag name itself.Tags should be on a separate tab, so the UI shouldn’t be so bad (granted BlueOcean doesn’t use the SCMCategory information yet and has hard-coded its tabs - against my advice - so yes the BO UI would be cluttered)
I have to say that I find Blue Ocean very hard to understand. Fixed width, non-responsive CSS. Headings like branches and pull requests when you have none. Very little clarity about what things are links and what aren’t. Projects listed in random order. No sense of where in the page hierarchy you are.
You can write a SCMFilter that only discovers “recent” tags - would work best for annotated tags - so that would limit the clutter to only those tags created (or worst case with last commit) say in the last week (or whatever you configure)
That’s really interesting.
Probably the biggest deal breaker of the tag-to-release approach for me is that on one project I’ve got a rather unusual structure with multiple projects inside one SCM root. So I have 10 jenkinsfiles in different folders for each project I want to build separately. It works great for what we want, but it means that I can’t easily tag each project separately.
We still name our releases with different versions per project and we don’t want to release and tag them all at once. So either we restructure our code completely, or we have some trick with naming tags like projectA-10.2.3 to identify which one should be released.