Conversation
…igurator/config.jelly`
…leConfigurator/config.jelly`
…igurator/config.jelly`
* remove unused `updateDeps` function declaration * use CSP compliant version of `st:bind`
…veConfigurator/config.jelly`
…blisher/config.jelly`
…figurator/config.jelly`
|
CLA Assistant Lite bot All contributors have signed the CLA ✍️ ✅ |
|
I have read the CLA Document and I hereby sign the CLA |
|
Though, this is a very old PR request but somehow surfaced again. It's not possible to accept and merger this PR. We are maintaining a feature status-quo for this older plugin and we encourage all of our customers to start using the newer Jenkins JFrog Plugin. Where all the new features and enhancements will be supported going forward. We will love to see the incoming PRs over there. |
The plugin is not accepting fixes to the plugin and is holding up the removal of the CSP checks (jenkinsci#1809) see jfrog/jenkins-artifactory-plugin#952 (comment) for the upstream comment
|
Time to update the readme that currently claims
to reflect the reality that this plugin is abandoned, and opening PRs is a waste of time? |
Thanks very much @shuvadipc for JFrog's ongoing support of Jenkins. When a plugin is no longer accepting changes, we recommend that the plugin be deprecated so that users of the plugin know that a replacement is available. That displays a message in the Jenkins plugin manager and allows the users some time to complete their transition to the new plugin. After some deprecation period, then the GitHub repository of the plugin can be archived so that it is even more clear that the plugin will not receive fixes or enhancements. We've recently seen that process in action with the Jenkins JaCoCo plugin. It was deprecated and the plugin documentation was updated to include a reference to the replacement plugin. After some time, the JaCoCo plugin GitHub repository was archived. The same process could be followed with this plugin so that we encourage more Artifactory users in Jenkins to update to the newest plugin. The steps to deprecate a plugin are simple and will encourage your users to move to the new plugin. |
* Remove Artifactory tests The plugin is not accepting fixes to the plugin and is holding up the removal of the CSP checks (#1809) see jfrog/jenkins-artifactory-plugin#952 (comment) for the upstream comment * Remove workaround for Artifactory in the CSPRule * remove gradle wrapper validateion ArtifactoryTests was the only hting using a gradle wrapper. Remove the validation as it is now failing.
There's an ongoing Content Security Project in Jenkins (blog post in case you want to know more) where we work towards making plugins CSP compatible. This initiative will also be followed by an implementation of a CSP enforcement mechanism in Jenkins core.
This PR targets to address all of the violations currently present in the plugin.
Note⚠️
None of this has been tested against a real artifactory instance. I've focused on making sure the behaviour is the same before and after my change, checked if all event handlers are properly attached, the same data is passed as arguments, if objects are created properly and in correct scope.
JENKINS-74041
Commit: 61062e3
Inline event handler has been extracted to a separate JS file. Inline usages of
st:bindinside JS script block have been replaced by CSP compliant version ofst:bind.Before the change
After the change
JENKINS-74042
Commit: c6e0a7d
Inline usage of
st:bindinside JS script block has been replaced by CSP compliant version ofst:bind.Before the change
After the change
JENKINS-74043
Commit: ccbb39e
Inline JS script block has been moved to its own separate JS file and included via
st:adjunct. Inline event handler has been extracted to a separate JS file.There's a part that I find problematic. Script attempts to find an element with ID of
useCredentialsPluginoverridingDeployerCredentials. I haven't found any usages of such ID in the repo, so script never finds one and throws an error. That error is caught by the catch block and script recursively calls itself again with 0 delay. While achieving nothing it causes a huge performance issue. I've for now set the delay for the recursive call to 1 second, and also log an error.Before the change
After the change
JENKINS-74044
Commit: 728d8e9
Inline event handler has been extracted to a separate JS file.
Before the change
After the change
JENKINS-74045
Commit: d1f2d85
Inline usage of
st:bindinside JS script block has been replaced by CSP compliant version ofst:bind.Before the change
After the change
JENKINS-74046
Commit: 1fcfdac
Inline usage of
st:bindinside JS script block has been replaced by CSP compliant version ofst:bind. Inline script block containing the declaration ofupdateDepshas been removed as no calls of the function were found in the repository.Before the change
After the change
JENKINS-74047
Commit: 171e1bb
Inline event handler and inline script block extracted to appropriate JS files.
Before the change
After the change
JENKINS-74048
Commit: 4708587
Inline usage of
st:bindinside JS script block has been replaced by CSP compliant version ofst:bind.Before the change
After the change
JENKINS-74049
Commit: 0fc0ab0
Removed the whole file as
customRadioButtontag is unused. Query: https://github.com/search?q=repo%3Ajfrog%2Fjenkins-artifactory-plugin%20customRadioButton&type=codeJENKINS-74050
Commit: 9262b4f
Inline event handler and inline script block extracted to appropriate JS files. Inline
st:bindremoved completely as the object it created was not used and had no methods.Before the change
After the change
JENKINS-74051
Commit: f92c8ee
Inline usages of
st:bindinside JS script block have been replaced by CSP compliant version ofst:bind.Before the change
After the change
JENKINS-74052
Commit: cfde874
Inline event handlers extracted to a JS file. Conditional script blocks also extracted to a JS file preserving the logic.
Before the change
After the change