On Thu 4 Jan 2018 at 06:57, Ari Maniatis <[email protected]> wrote:
> 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 > You shouldn’t be manually disabling branches. The disabled state should be controlled by the multibranch folder. Or could you explain what you are doing? (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) > * 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) 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) > > 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 [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/jenkinsci-users/13b94c91-3864-4a1e-acd8-f450bfb87078%40googlegroups.com > <https://groups.google.com/d/msgid/jenkinsci-users/13b94c91-3864-4a1e-acd8-f450bfb87078%40googlegroups.com?utm_medium=email&utm_source=footer> > . > 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/CA%2BnPnMxYg%3D3ENSuTHTenARv%3D3JkZyQ1R3O8vw67Vd0HGmHjuZw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
