Job Dsl Whitelisting Option - #968
Conversation
Added UI for job whitelist. Added handling for Step, Publisher, Wrapper, SCM and Trigger contexts, as well as externally defined raw Configure blocks. Externally defined blocks for the contexts above are also supported. Still need to add info file for whitelist feature and add tests,
Fixed test failure. Added help file (not complete yet)
Two things I think I still have to consider. 1) This should probably go in the wiki section since it's so verbose. 2) Should I move out of the Advanced section.
|
How do I look at the code narc results that Jenkins references, here - Execution failed for task ':job-dsl-core:codenarcMain'.
|
|
Nevermind. I ran on my local, and can see the codeNarc report. I will fix the issues, and add the changes to this pull request. |
updated code to be stop fighting with code narc rules.
Not even close to complete. Have a little of the WhitelistContextHelper done, but not being called from anything yet or built into the UI
seperated out 1 whitelist into two fields - allowed external classes and raw job dsl allowed -
|
This feature is now considered complete in my book, so I would love to hear feedback on whether or not it can get it merged into the master branch. |
|
Hi @smoyen! Thanks for working on this. I like the XML based approach for validating generated config, but this is a huge PR and I'm not sure how many people would find this useful. I would like keep this PR open for a while to gather some feedback. Can you create a corresponding issue in JIRA to increase visibility? |
|
may i suggest squashing these commits? also not sure if this PR could be split into smaller pieces, but it would make it easier to consume. |
|
Thanks for getting back to me @daspilker. The Jira ticket is created so we can see what we hear. I know that a decent amount of companies (that I talked to at the Jenkins conference last year) who have a centralized build and deploy team, and are trying to move pockets of dev ops back into a centralized build and deploy pipeline have expressed similar interests due to still wanting to maintain the same level of security and control when moving from a customized build/deploy system to Jenkins. Also, I can move the whitelisting options into the advanced section as to not clutter up the plugin for a feature that is not used all that often (let me know if you think that's a good idea). |
|
@smoyen |
Support for custom config blocks whitlisting for steps, triggers, publishers, and wrappers. Additional tests and updated help blocks. Also moved the whitelisting feature from the main plugin widget section to the Advanced section.
|
@smoyen sorry for answering so late Are you interested in picking this up again? |
|
Can one of the admins verify this patch? |
|
Build finished. |
|
Would be great to have this |
7 participants
Whitelisting allows administers to only allow a subset of "approved" job dsl to be processed to create new jobs. We will use in our environment by allowing them to define the job dsl file in source control, and by adding these whitelisting options to all seed jobs to ensure they are using only "approved" dsl. In our environment, developers will not have access to the seed job itself, so we can set the whitelist, and all they need to do is check in their job-dsl.groovy code to their branch.
See the help pages for the added text boxes for more detailed info.
Thanks!