From 3fcac4a52343c9502282aff08381dc3e42cce8a4 Mon Sep 17 00:00:00 2001 From: Devin Nusbaum Date: Thu, 24 Jan 2019 16:43:41 -0500 Subject: [PATCH 1/2] Use whitelisted APIs from workflow-support 2.22 --- .../get-build-cause/getBuildCause.groovy | 28 +++++++++++++------ 1 file changed, 19 insertions(+), 9 deletions(-) diff --git a/pipeline-examples/get-build-cause/getBuildCause.groovy b/pipeline-examples/get-build-cause/getBuildCause.groovy index 7f122d2..e09fb5d 100644 --- a/pipeline-examples/get-build-cause/getBuildCause.groovy +++ b/pipeline-examples/get-build-cause/getBuildCause.groovy @@ -1,15 +1,25 @@ -// There is no direct access to the build Causes from the Pipeline, but you can -// get this by using the `currentBuild.rawBuild` variable, as shown below. +// As of Pipeline Supporting APIs v2.22, there is a whitelisted API to access +// build causes as JSON that is available inside of the Pipeline Sandbox. // Get all Causes for the current build -def causes = currentBuild.rawBuild.getCauses() +def causes = currentBuild.getBuildCauses() // Get a specific Cause type (in this case the user who kicked off the build), // if present. -def specificCause = currentBuild.rawBuild.getCause(hudson.model.Cause$UserIdCause) +def specificCause = currentBuild.getBuildCauses('hudson.model.Cause$UserIdCause') -// If you see errors regarding 'Scripts not permitted to use method...' approve -// these scripts at JENKINS_URL/scriptApproval/ - the UI shows the blocked methods - -// See the Javadoc for Cause for more information on what's in Causes, etc at: -// http://javadoc.jenkins-ci.org/hudson/model/class-use/Cause.html +// The JSON data is created by calling methods annotated with `@Exported` for +// each Cause type. See the Javadoc for specific Cause types to check exactly +// what data will be available. +// For example, for a build triggered manually by a specific user, the resulting +// JSON would be something like the following: +// +// [ +// { +// "_class\": "hudson.model.Cause$UserIdCause", +// "shortDescription": "Started by user anonymous", +// "userId": "tester", +// "userName": "anonymous" +// } +// ] +// cf. https://javadoc.jenkins-ci.org/hudson/model/Cause.UserIdCause.html From 285cc2a0833ee8b2eba7eec9d8b8bde0d9139b6b Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Oliver=20Gond=C5=BEa?= Date: Wed, 15 Jan 2020 09:23:57 +0100 Subject: [PATCH 2/2] typo in BEST_PRACTICES.md --- docs/BEST_PRACTICES.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/BEST_PRACTICES.md b/docs/BEST_PRACTICES.md index 61d78f4..454356b 100644 --- a/docs/BEST_PRACTICES.md +++ b/docs/BEST_PRACTICES.md @@ -6,7 +6,7 @@ This is a collection of tips, advice, gotchas and other best practices for using * Do all real work that involves running a shell script, building, etc, within `node` blocks, so that it actually happens on a real executor, rather than a flyweight executor on the master node. * Get your flows from source control - `Jenkinsfile`s, loading libraries, global [CPS](https://en.wikipedia.org/wiki/Continuation-passing_style) library, you name it - but if you pull the main flow from SCM (i.e., Multibranch with `Jenkinsfile`s or `Pipeline from SCM`), be aware that you may need to whitelist a lot of method calls in the script security plugin. By getting your flows from source control, you benefit from `Jenkinsfile` versioning and also testing and merging against your CD Pipeline definition. * `input` shouldn’t be done within a `node` block. For `input` step is recommended to use `timeout` in order to avoid waiting for an infinite amount of time, and also control structures (`try/catch/finally`). -* As Pipeline usage is adopted for multiple projects and teams in an organization, common patterns should be stored in [Shared Libraries](https://jenkins.io/doc/book/pipeline/shared-libraries/). It is also an escape value for allowing out-of-sandbox execution in a safe context. +* As Pipeline usage is adopted for multiple projects and teams in an organization, common patterns should be stored in [Shared Libraries](https://jenkins.io/doc/book/pipeline/shared-libraries/). It is also an escape valve for allowing out-of-sandbox execution in a safe context. * When writing functions, use unique names in your pipeline script and avoid using built-in/pre-defined items (such as "build", "stage", etc). Using pre-defined methods may result in runtime issues, such as generating a `sandbox.RejectedAccessException` error when using build job DSL. * Make use of the available [Pipeline Development Tools](https://jenkins.io/doc/book/pipeline/development/#pipeline-development-tools) for debugging your Pipeline as code. * Use [Multibranch Pipeline](https://jenkins.io/doc/book/pipeline/multibranch/) for project collaboration, new features (developed in separate branches) are validated before merging them to the master branch. Besides, it comes with automating features out-of-the-box (webhooks).