On 4 January 2018 at 7:19:53pm, Stephen Connolly ( [email protected]) wrote:
* 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? 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. Thanks for your ideas. I think Jenkins could do more to make releasing a really first class concept in the UI and pipeline. But there are still pieces missing (eg. being able to set a build to keep forever from the pipeline). Ari -- 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/CAJHfvuD_Gm%3D2cpoH1Uu0%3D2-O2JFQauGiGzctTSvmuGcJBFkWLw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
