[Multi-Branch Project Plugin] Should it be possible to reconfigure branches?

[Jochen Fuerbacher]

Hello there,

i was wondering about the behavior of the Multi-Branch Project Plugin.
The wiki page says "Each branch has its own sub-project. Sub-projects are just like normal projects, except they can't be configured directly and they are listed on the main (parent) project's page."

However, when I click on such a branch / sub-project, I CAN confgure them directly. Is that wanted?
If not, is it still possible, that the sub-project configuration can change?

One problem of this behavior is, that the sync of the branches leads to changes in the sub-project config files (temporarily disable and re-enable of the job), which get tracked by JobConfigHistory (if installed). See: https://issues.jenkins-ci.org/browse/JENKINS-33682

Jochen Fürbacher

[Arnaud Héritier]

As far as I can see you can only "View Configuration" which displays the configuration form but doesn't allow you to save it (yes I find it a little bit ugly too)

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/234ad651-18f7-43bc-85b6-aa381e6dd5ff%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

-----

Arnaud Héritier

http://aheritier.net

Mail/GTalk: aheritier AT gmail DOT com

Twitter/Skype : aheritier

[Jesse Glick]

On Tue, Jun 21, 2016 at 6:49 AM, Arnaud Héritier <aher...@gmail.com> wrote:
> you can only "View Configuration" which displays the
> configuration form but doesn't allow you to save it (yes I find it a little
> bit ugly too)

JENKINS-12548

[Jochen Fuerbacher]

It's not possible to reconfigure scm. But it's still possible to do some config changes like adding build steps or post build actions.

[Matthew DeTullio]

I just released 0.5, which fixes the job configuration history craziness.

As for the "except they can't be configured directly" bit... this was true at one point (version 0.1) but since then the interworkings of the multi-branch-project-plugin have changed to use a hidden template.  By doing that, many headaches were solved, but with the trade-off that the sub-projects became directly configurable.  Any direct configuration will be overwritten by the sync/indexing.  I updated the wiki page to clear that up a bit.  I think the only way to prevent direct configuration involves using project-based matrix authorization as your security strategy.

[Jochen Fuerbacher]

Thank you very much, Matthew.

[Jesse Glick]

On Fri, Jul 1, 2016 at 10:22 PM, Matthew DeTullio <mjdet...@gmail.com> wrote:
> I think the only way to prevent direct configuration involves using
> project-based matrix authorization as your security strategy.

`branch-api` does this automatically, FWIW.

[Matthew DeTullio]

branch-api only controls permission of the multi-branch project itself if it's in an OrganizationFolder.  There is no mechanism to always restrict configuration permission of the children (branch jobs).  It requires an override of hudson.model.Job#getACL() as you've done for Pipeline (https://github.com/jenkinsci/workflow-job-plugin/blob/workflow-job-2.3/src/main/java/org/jenkinsci/plugins/workflow/job/WorkflowJob.java#L350 and https://github.com/jenkinsci/workflow-multibranch-plugin/blob/workflow-multibranch-2.8/src/main/java/org/jenkinsci/plugins/workflow/multibranch/BranchJobProperty.java#L61).  This is not possible to do in multi-branch-project-plugin because I make direct use of the existing FreeStyleProject, MavenModuleSet, IvyModuleSet, and MatrixProject types.  Extending these types to override things such as the ACL was an attempted and failed approach (easily do-able for FreeStyleProjects but I remember having some headaches with MavenModuleSet), but admittedly the multi-branch types for each of these should be in their respective plugins or entirely separate.

Anyway, without the override, hudson.model.Job#getACL() delegates to the authorization strategy, not the parent's ACL.  Project-based matrix auth will attempt to inherit from the parent ACL though.  In turn, this makes the branch jobs open to everyone unless the matrix auth property is set to strip the config and delete permissions by using the "disallow inheritance" (or whatever it's called) setting on matrix auth property.

[Jesse Glick]

On Thu, Jul 7, 2016 at 10:32 PM, Matthew DeTullio <mjdet...@gmail.com> wrote:
> This is not possible to do in multi-branch-project-plugin because I make
> direct use of the existing FreeStyleProject, MavenModuleSet, IvyModuleSet,
> and MatrixProject types. Extending these types to override things such as
> the ACL was an attempted and failed approach

True, this is a missing core API. See JENKINS-32596.