-
-
Notifications
You must be signed in to change notification settings - Fork 18
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
[DO NOT MERGE] Check Restricted annotation instead #7
[DO NOT MERGE] Check Restricted annotation instead #7
Conversation
@daniel-beck if jenkins/util/xml/XMLUtils is |
Do not recall. Probably just a matter of not introducing APIs in security releases. Could be unrestricted in trunk if necessary. |
For now, |
If you decide changes to multi-branch-project-plugin are necessary, I can reopen the ticket to remove it from the plugins library so you can avoid that work. |
No strong opinion, this just means the plugin uses something from core not considered public (and therefore stable) API, this may or may not break at some time in the future, but it will impact modernization of the plugin. No action needed I guess if the plugin is abandoned and discourages further use. |
|
@daniel-beck |
@vivek Well, you've already done what this should get you to do, so, yes 👍 |
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.
I would rather vote for a separate branch for now. The current report is already useful, so having it in a branch with docs LGTM.
🐝
The context from the Jenkins Pipeline run is:
|
The context from the Jenkins Pipeline run is:
|
Build failed; the context from the latest run is: Expand to view
|
Because jenkinsci/plugin-pom#61
This changes the behavior of this scanner to find usages of
@Restricted
annotated APIs of core in plugins. Before the above fix to the plugins POM, this was possible without breaking the build.DO NOT MERGE, this should either be a separate long-living branch ("restricted-usage-in-plugins") or be integrated into regular deprecated API checks. Not sure which. Currently there's no facility to annotate the type of finding, so merging into the same reports would be weird.
Notable violations:
jenkins/util/SystemProperties
jenkins/util/xml/XMLUtils
hudson/model/Computer$DisplayExecutor
Plus quite a few usages of
Messages
, which were all@Restricted
in jenkinsci/jenkins#2656PR build output (without evil CSS): https://ci.jenkins.io/job/Infra/job/deprecated-usage-in-plugins/job/PR-7/1/artifact/output/usage-by-plugin.html