-
Notifications
You must be signed in to change notification settings - Fork 143
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for programmatically generating OrganizationFolders #145
Conversation
e86e91e
to
2dd56e1
Compare
import javax.servlet.ServletException; | ||
|
||
import org.acegisecurity.AccessDeniedException; | ||
import org.acegisecurity.Authentication; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My IDE alphabetized imports.
org.acegisecurity.Authentication
is an addition.
fb7ef20
to
4df7bef
Compare
@@ -695,7 +730,7 @@ public String getDescription() { | |||
); | |||
} | |||
|
|||
//@Override TODO once baseline is 2.x | |||
@Override |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This appears to have happened, so I did the TODO.
@@ -676,7 +711,7 @@ public String getCategoryId() { | |||
* | |||
* @return A string with the description. {@code TopLevelItemDescriptor#getDescription()}. | |||
*/ | |||
//@Override TODO once baseline is 2.x | |||
@Override |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This appears to have happened, so I did the TODO.
@@ -665,7 +700,7 @@ public TopLevelItem newInstance(ItemGroup parent, String name) { | |||
* | |||
* @return A string with the category identifier. {@code TopLevelItemDescriptor#getCategoryId()} | |||
*/ | |||
//@Override TODO once baseline is 2.x | |||
@Override |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This appears to have happened, so I did the TODO.
@awittha |
… child of a ComputedFolder.
…d default-enabled MultiBranchProjectFactories if the projectFactories are empty. This allows OrganizationFolders' projectFactories to be set by code that creates them and avoids always adding enabled-by-default MultiBranchProjectFactories.
…iBranchProjectFactory implementations during OrganizationFolder#onCreatedFromScratch()
…when children of a ComputedFolder
6777159
to
a54aad9
Compare
Added unit tests & rebased off of latest |
* doesn't look like we can actually compute children during a unit test. | ||
* Normally we'd want to create the OrganizationFolder here | ||
* to match the "real" Jenkins workflow as closely as possible | ||
*/ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@awittha
Why can't we compute children during a unit test?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In my own code, when I want to kick off the computation of children of a ComputedFolder in a "safe" way, I used ComputedFolder#scheduleBuild(...)
.
This didn't actually result in any computations happening, during the unit tests - the actual computeChildren(...)
method was never called.
I didn't attach a debugger, but my guess is that when it tries to actually schedule a build ( https://github.com/jenkinsci/cloudbees-folder-plugin/blob/master/src/main/java/com/cloudbees/hudson/plugins/folder/computed/ComputedFolder.java#L580 ), there isn't actually a build queue in the unit test's Jenkins "instance" (or maybe no executors...)?
In any case, it isn't terribly important to actually compute children as this code doesn't activate when an OrganizationFolder
is created as part of a ComputedFolder
computation, but merely when an OrganizationFolder
's parent is a ComputedFolder
- which we can set up without actually having to have a working ComputedFolder
during the test.
Should I update the comment to be more specific to that effect - that it doesn't work out of the box and we don't really need it anyway - do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you want to add a little more to say why it is not a big deal, that'd be great.
Great work on this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updated the comment; new text:
* We don't actually need to compute children during a unit test.
* We just need an OrganizationFolder to have this ComputedFolder
* as its parent.
*
* Since item parents are set on the item when constructing it,
* we can do that when we create the OrganizationFolder.
*
* Also, #scheduleBuild(...) to enqueue a computeChildren
* doesn't work out-of-the-box in the current unit-test setup.
…he ComputedFolder in OrganizationFolderTest
@reviewbybees Can I get another set of eyes on this it looks good to me, but I'd like a second upvote. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- Stick to the codes convention of imports order
- MultibranchProject should use the ComputedFolder generalization too
@@ -24,7 +24,43 @@ | |||
|
|||
package jenkins.branch; | |||
|
|||
import antlr.ANTLRException; | |||
import static jenkins.scm.api.SCMEvent.Type.CREATED; | |||
import static jenkins.scm.api.SCMEvent.Type.UPDATED; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
static after non static
@bitwiseman well given that it mirrors the exact change made in this PR, from an API perspective I would rather the two go hand in hand (it's just one line to change anyway) |
4b2a813
to
3798c55
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We have been badly burned by Guava, consequently any plugins for which I have any say are not using Guava. The rest is fine.
No need to seek re-approval once Guava is removed
Better late than never |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Once you figure out what’s up with the build failure
6d8c8cb
to
5d50dcc
Compare
Thanks, y'all! |
In my own life, I am building a Jenkins plugin that adds the ability to generate
OrganizationFolder
s for a user against an SCM server (each of which will then generateMultiBranchProjects
for each repo, as anOrganizationFolder
does).Suppress modify permissions in OrganizationFolder when it is a direct child of a ComputedFolder
The
MultiBranchProject
detects if it is a child of anOrganizationFolder
and hides from users the ability to directly update and delete it, because it is managed programmatically by theComputedFolder
aspect ofOrganizationFolder
.OrganizationFolder
itself does not do this, so the automatically-generated organization folders can be modified and deleted by users after their creation. This isn't ideal.I have taken the (above-linked) code block from
MultiBranchProject
that hides the modification permissions when it should, and added it toOrganizationFolder
I have made one change: Instead of checking for a specific implementation parent class, it will hide those permissions any time it is a child of a
ComputedFolder
- so anyone that computes & generatesOrganizationFolder
s will get the correct behavior regardless of their specific implementation class' type.I would have preferred to keep this entirely in my own plugin code by extending
OrganizationFolder
but it is afinal
class and so I must make the code change here.I believe this is a low-risk contribution with value to all plugin authors, not just myself.
I don't know of anyone (or any plugin) that currently puts
OrganizationFolder
s inComputedFolder
s and expects human users to be able to modify & delete them through the WebUI. If any such users do exist, though, this change would break their workflow.Do not use default MultiBranchProjectFactory(ies) onCreatedFromScratch if some exist
Currently, when an OrganizationFolder is created the
onCreatedFromScratch()
method will add all enabled-by-default MultiBranchProjectFactory types to the OrganizationFolder.This updates that behavior to skip adding the factories if and only if there were already some factories set. This allows code that creates an OrganizationFolder to also specify which project factories the folder should use, and ensures that the OrganizationFolder won't go and add additional factories on its own.
I believe this is a low-risk contribution.
Only other workflows that were programmatically creating OrganizationFolders and relying on the default MultiBranchProjectFactory classes being added to the folders in addition to at least one non-default factory that the workflow added would experience a change in behavior.