add symbol annotations to BranchProperty and BranchPropertyStrategy subclasses#192
add symbol annotations to BranchProperty and BranchPropertyStrategy subclasses#192car-roll merged 9 commits intojenkinsci:masterfrom
Conversation
| /** | ||
| * Our {@link hudson.model.Descriptor}. | ||
| */ | ||
| @Symbol("buildRetention") |
There was a problem hiding this comment.
The DataBoundConstructor for this class includes BuildDiscarder as an argument. BuildDiscarder is an abstract class, so I was not sure if I needed to add Symbol annotation for BuildDiscarder subclasses? The same question applies to some other classes below.
There was a problem hiding this comment.
Yes, ideally we would track down all implementations of BuildDiscarder and make sure they have symbols as well, but the only implementation I am aware of is LogRotator and that already has a symbol, see here.
That said, I don't think that BuildRetentionBranchProperty is intended to be directly configured by users because it doesn't show up in the UI when configuring a property strategy for a multibranch projects (not sure why, I don't see an isApplicable override in the descriptor), so maybe we shouldn't add a symbol for it?
There was a problem hiding this comment.
@car-roll Yeah, I think they might show up in the UI in some context, I'm just not sure what those contexts are, because I don't see them as options when I configure a property strategy for a Multibranch Pipeline.
UntrustedBranchProperty implements BranchPropertyDescriptor.isApplicable so that it only shows up when the items inside of the MultiBranchProject extend hudson.model.Project, but WorkflowJob directly extends hudson.model.Job, so it makes sense that that one didn't show up in my testing.
After some digging it looks like Multibranch Pipelines have a DescriptorVisibilityFilter that suppresses BuildRetentionBranchProperty and RateLimitBranchProperty, so that explains why I didn't see them either in my testing.
So as far as I can tell, adding symbols to these types doesn't matter for Multibranch Pipelines, but we could still go ahead and add them for whatever projects do support them.
There was a problem hiding this comment.
RateLimitBranchProperty already has a symbol annotation so we're good to go there.
There was a problem hiding this comment.
Looks like the symbol is only for the descriptor for the job property, but I think we want one on the descriptor for the branch property.
|
bouncing for CI |
| /** | ||
| * Our {@link hudson.model.Descriptor}. | ||
| */ | ||
| @Symbol("buildRetention") |
There was a problem hiding this comment.
Yes, ideally we would track down all implementations of BuildDiscarder and make sure they have symbols as well, but the only implementation I am aware of is LogRotator and that already has a symbol, see here.
That said, I don't think that BuildRetentionBranchProperty is intended to be directly configured by users because it doesn't show up in the UI when configuring a property strategy for a multibranch projects (not sure why, I don't see an isApplicable override in the descriptor), so maybe we shouldn't add a symbol for it?
| /** | ||
| * Our {@link Descriptor}. | ||
| */ | ||
| @Symbol("untrustedCode") |
There was a problem hiding this comment.
I also don't see this show up as an option for Multibranch Pipelines, so IDK if we want a symbol or not. In this case, I think it's because Pipelines extend Job rather than Project, but I'm not sure.
If we do keep the symbol, maybe untrustedBranches would be better?
There was a problem hiding this comment.
I'll remove it if it's not configurable. Probably best to keep it consistent with UI. Same goes with BuildRetentionBranchProperty that you mentioned in the above comment.
There was a problem hiding this comment.
It might be configurable for some other implementation of MultiBranchProject, but I'm not sure what those might be.
There was a problem hiding this comment.
Cool, I'll double check before I do anything
| /** | ||
| * Our {@link BranchPropertyStrategyDescriptor}. | ||
| */ | ||
| @Symbol("allBranchesSameProperties") |
There was a problem hiding this comment.
Any thoughts on naming here (or for NamedExceptionsBranchPropertyStrategy)? I think I saw that you were considering sameProperties elsewhere? The display names for these types in the UI are "All branches get the same properties" and "Named branches get different properties", so I just tried to pick names that were close to what users would be used to from the UI. Maybe Properties is redundant since the type is BranchPropertyStrategy, so we could use allBranchesSame and namedBranchesDifferent or something? IDK what is best.
There was a problem hiding this comment.
Yeah, I removed the suggestions because i thought i was overthinking it. But yeah, I thought the wording was a bit redundant. I'm fine with allBranchesSame and namedBranchesDifferent. I like to reduce names as much as possible, but I guess if you reduce it too much you can lose the meaning (like same and differentNames)
| /** | ||
| * Our {@link Descriptor}. | ||
| */ | ||
| @Symbol("untrustedBranches") |
There was a problem hiding this comment.
I should have thought about this more before I recommended untrustedBranches, but since the base type is BranchProperty I think the best symbol here is just untrusted.
|
I'm not sure why there are dependency issues in CI and not locally, but going to try to address them |
The problem is that the CI builds runs on multiple branches ( |
|
Looks like there is also a conflict for |
|
I'll give the update a shot |
This reverts commit 21ac3a0.
|
managed to resolve the issues using the BOM as well as setting |
adding symbol annotations to
BranchPropertyandBranchPropertyStrategysubclasses to make databinding easier