Skip to content
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

add symbol annotations to BranchProperty and BranchPropertyStrategy subclasses #192

Merged
merged 9 commits into from
May 6, 2020

Conversation

car-roll
Copy link
Contributor

adding symbol annotations to BranchProperty and BranchPropertyStrategy subclasses to make databinding easier

@car-roll car-roll requested review from dwnusbaum and kshultzCB April 27, 2020 22:56
@@ -84,6 +85,7 @@ public Boolean run() {
/**
* Our {@link hudson.model.Descriptor}.
*/
@Symbol("buildRetention")
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Contributor Author

@car-roll car-roll Apr 28, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I do see a jelly file for BuildRetentionBranchProperty here as well as UntrustedBranchProperty here
Or does having a jelly file not always mean there is a UI element?

Copy link
Member

@dwnusbaum dwnusbaum Apr 29, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

RateLimitBranchProperty already has a symbol annotation so we're good to go there.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@car-roll
Copy link
Contributor Author

bouncing for CI

@car-roll car-roll closed this Apr 28, 2020
@car-roll car-roll reopened this Apr 28, 2020
@@ -84,6 +85,7 @@ public Boolean run() {
/**
* Our {@link hudson.model.Descriptor}.
*/
@Symbol("buildRetention")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

@@ -120,6 +121,7 @@ public UntrustedBranchProperty(String[] publisherWhitelist) {
/**
* Our {@link Descriptor}.
*/
@Symbol("untrustedCode")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Contributor Author

@car-roll car-roll Apr 28, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It might be configurable for some other implementation of MultiBranchProject, but I'm not sure what those might be.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cool, I'll double check before I do anything

@@ -81,6 +82,7 @@ public DefaultBranchPropertyStrategy(@CheckForNull BranchProperty[] props) {
/**
* Our {@link BranchPropertyStrategyDescriptor}.
*/
@Symbol("allBranchesSameProperties")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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)

@dwnusbaum dwnusbaum self-requested a review May 1, 2020 14:05
@@ -120,6 +121,7 @@ public UntrustedBranchProperty(String[] publisherWhitelist) {
/**
* Our {@link Descriptor}.
*/
@Symbol("untrustedBranches")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@car-roll
Copy link
Contributor Author

car-roll commented May 1, 2020

I'm not sure why there are dependency issues in CI and not locally, but going to try to address them

@dwnusbaum
Copy link
Member

dwnusbaum commented May 1, 2020

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 (recommendedConfigurations in the Jenkinsfile), and there was a recent update that changes the LTS version of one of those branches, see jenkins-infra/pipeline-library#92, and that version apparently changed some dependency versions leading to enforcer errors. You should see the same errors locally if you tried updating the Jenkins version to 2.222.3.

@dwnusbaum
Copy link
Member

Looks like there is also a conflict for org.slf4j:slf4j-jdk14, the requested version in the new core version is 1.7.26 IIUC. I think the right way to fix these issues it to update to the newest version of the parent POM so that the core dependencies use the core BOM and then update the baseline here to 2.176.4, but I'm not sure if that would work.

@car-roll
Copy link
Contributor Author

car-roll commented May 1, 2020

I'll give the update a shot

@dwnusbaum
Copy link
Member

You might run into some Mockito problems once the core version is updated, see #160 which hit similar errors that you did and #184 which might fix those problems if you end up hitting them.

@car-roll car-roll closed this May 6, 2020
@car-roll car-roll reopened this May 6, 2020
@car-roll car-roll requested a review from dwnusbaum May 6, 2020 19:58
@car-roll
Copy link
Contributor Author

car-roll commented May 6, 2020

managed to resolve the issues using the BOM as well as setting reuseForks to `false. Thanks @dwnusbaum for the tip! This should resolve the problems in #194 and #160

@car-roll car-roll merged commit 97f7edb into jenkinsci:master May 6, 2020
@car-roll car-roll deleted the symbolize branch May 6, 2020 20:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants