Recent Blog Posts

Updated on Jan 10, 2019: The deprecated protocols were removed in Remoting 3.40+ and Jenkins 2.214+. See jira:JENKINS-60381[Remove old, deprecated Remoting protocols] for more information and links. There are upcoming changes in Jenkins "core" which may require extra steps when upgrading Jenkins. If you use configuration management for Jenkins agents, please read this announcement carefully. If you have ever seen messages like "Channel is already closed" or "Remote call failed" in your build logs, you have already met Jenkins Remoting. Remoting is an agent executable and a library implementing the communication layer between Jenkins controllers and their agents (including communication protocols, distributed calls and classloading). It is also used in several other cases: Maven Integration Plugin, Remoting-based CLI, etc. In order to make it clear what’s changing in Jenkins Remoting, I have documented the various components on the Remoting’s sub-project page, and will try to publish regular updates about the status of Remoting to this site and the developer mailing list. In this post I would like to provide an update on the Remoting roadmap and to announce two major incoming changes: deprecation of old protocols and upgrade to Java 8. Both changes will take place in one of the next Weekly releases. ETA is Jenkins 2.75 on Aug 20, 2017. Below are details on the incoming changes and compatibility notes. Old Remoting Protocols Deprecation It has been almost one year since the release of JNLP4-connect protocol in Remoting 3.0. This protocol has been enabled by default since 2.46.x, and so far it demonstrates good stability being compared to JNLP2 and JNLP3 protocols. At the governance meeting we decided to disable old Remoting protocols (JNLP/JNLP2 + CLI1) in new installations by default. There are 3 reasons for it: Maintenance of multiple protocols takes a lot of extra effort. The JNL2 NIO engine is complex and barely diagnosable. There are known issues in JNLP2 connection management (see the protocol’s Errata). In many cases update to JNLP4 was a resolution JNLP1/JNLP2/CLI1 are unencrypted, and it is not something Jenkins users may expect in 2017 It is tracked as JENKINS-45841 in Jenkins JIRA. How? When Jenkins is started in the new installation mode with enabled Installation Wizard, old protocols will be disabled Jenkins shows an administrative warning when obsolete protocols are enabled Compatibility notes Older instances won’t be affected by the disabling of the older JNLP1/JNLP2 protocols, which will still be enabled for them. Newly created instances which skip, or disable, the Setup Wizard will not be affected either. "New" Jenkins instances installed via setup wizard may be affected in edge cases. For example: Agents with Remoting older than 3.0 will be unable to connect. Mitigation: Before updating make sure Remoting is not bundled custom Docker images, AMIs, etc. Swarm Plugin: old versions of Swarm Client (before 3.3) will be unable to connect to Jenkins, because Remoting 2.x is bundled Mitigation : Update Swarm Client Very old jenkins-cli.jar without CLI2 support will be unable to connect. Mitigation : Do not use Remoting-based CLI on new instances (see this blogpost) Upgrade to Java 8 Starting with version 2.54, Jenkins requires Java 8 to run ( announcement blog post). This version is also required for Jenkins LTS 2.60.1. Remoting continued to support Java 7 for a while for backporting purposes, but it will be also upgraded to Java 8 in the Remoting 3.11 release. This Rremoting version is expected to be available in Jenkins 2.75 (ETA: Aug 20, 2017). This change is tracked as JENKINS-43985. Compatibility notes The update does not cause compatibility issues in common use-cases. However, there may be issues in custom Jenkins core builds and packaging. There are several examples below. Jenkins instances with built-in Remoting versions will NOT be affected, Java 8 is already required there Users of community-provided Docker packages ( docker-agent, docker-inbound-agent) will NOT be affected, Java 8 is already required there Custom Jenkins WAR file builds targeting Java 7 may fail to build/run if they bundle Remoting 3.11 or later Custom Jenkins agent instances (manually installed hosts, VM snapshots, Docker packages, AMIs, etc.) may fail if they download the latest Remoting version and use Java 7 Java 9 support As with Jenkins core, Java 9 not supported and not tested in Remoting. It may work in some configurations, but it is not guaranteed. As a consequence, it is not recommended to run Remoting with Java 9 right now. It is also not recommended to use Maven Integration Plugin to run builds on Java 9. What’s next? There are some ongoing activities in the Remoting sub-project: Stability and Diagnosability improvements ( JENKINS-38833) Why? When it comes to Remoting issues, it is really hard to diagnose them Recently I have published some slides about preventing and diagnosing issues, but I want the behavior to be more stable by default This Epic lists my plans about Remoting issues and papercuts I would like to fix this year Remoting Work Directories ( JENKINS-44108) For a long time logging was disabled by default in Java Web Start (JNLP) and SSH agents, because Remoting had no option to determine where to store such data before connecting to the controller The new Remoting Work Directory feature (since Remoting 3.8) offers such storage, which is also used for storing JAR caches and for checking workspace writeability before accepting builds. This Epic is about enabling Remoting work directories by default in common Agent launcher types. Remoting Upgradeability ( JENKINS-44099) Right now Remoting is not being upgraded automatically on JNLP agents, it is supported only for Windows service agents starting from Jenkins 2.50 On the Jenkins controller side it is required to upgrade the Jenkins core in order to pick Remoting fixes. This Epic aims simplifying the upgrade procedure for most common cases. If you are interested in contributing to these tasks, or others in the Remoting sub-project, please feel free to reach out via the issue tracker or #jenkins IRC channel. If you are coming to Jenkins World, you can also find me at the "Ask the Experts" booth there. See more info about Ask the Experts here. Useful links Remoting Sub-Project on Jenkins website Remoting Release Notes Remoting documentation on GitHub My slides about Remoting issues troubleshooting

This is a guest post by Pui Chee Chen, Product Manager at Microsoft working on Azure DevOps open source integrations. Recently, we improved the Azure Credential plugin by adding a custom binding for Azure Credentials which allows you to use an Azure service principal (the analog to a service or system account) via the Credentials Binding plugin. This means it’s now trivial to run Azure CLI commands from a Jenkins Pipeline. We also recently published the first version of the Azure App Service plugin which makes it very easy to deploy Azure Web Apps directly from Jenkins Pipeline. While we’ll have much more to discuss in our Jenkins World presentation on Azure DevOps open source integrations, in this blog post I wanted to share some good snippets of what is possible today with Jenkins Pipeline and Azure. First, a simple example using the Azure CLI to list resources in the subscription: // Scripted // node { /* .. snip .. */ stage('Deploy') { withCredentials([azureServicePrincipal('principal-credentials-id')]) { sh 'az login --service-principal -u $AZURE_CLIENT_ID -p $AZURE_CLIENT_SECRET -t $AZURE_TENANT_ID' sh 'az account set -s $AZURE_SUBSCRIPTION_ID' sh 'az resource list' } } } // Declarative // azureServicePrincipal() cannot be used in Declarative Pipeline until JENKINS-46103 is resolved. Once a Pipeline can interact with Azure, there are countless ways one could implement continuous delivery with Jenkins and Azure. From a deploying a simple webapp with the Azure App Service plugin and the azureWebAppPublish step, or a more advanced container-based delivery pipeline to deliver new containers to Kubernetes via Azure Container Service. With the Docker Pipeline plugin and a little bit of extra scripting, a Jenkins Pipeline can also build and publish a Docker container to an Azure Container Registry : // Scripted // import groovy.json.JsonSlurper node { def container def acrSettings withCredentials([azureServicePrincipal('principal-credentials-id')]) { stage('Prepare Environment') { sh 'az login --service-principal -u $AZURE_CLIENT_ID -p $AZURE_CLIENT_SECRET -t $AZURE_TENANT_ID' sh 'az account set -s $AZURE_SUBSCRIPTION_ID' acrSettings = new JsonSlurper().parseText( sh(script: "az acs show -o json -n my-acr", returnStdout: true)) } stage('Build') { container = docker.build("${acrSettings.loginServer}/my-app:${env.BUILD_ID}") } stage('Publish') { /* https://issues.jenkins.io/browse/JENKINS-46108 */ sh "docker login -u ${AZURE_CLIENT_ID} -p ${AZURE_CLIENT_SECRET} ${acrSettings.loginServer}" container.push() } stage('Deploy') { echo 'Orchestrating a new deployment with kubectl is a simple exercise left to the reader ;)' } } } // Declarative // If you have been following our Azure Blog, you may have noticed we have shipped a lot of updates to provide better support for Azure on Jenkins, and vice versa, such as: Hosted Jenkins. New Solution Template in Azure Marketplace lets you spin up a Jenkins Controller on Azure in minutes. Not only is it easy and fast, the solution template gives you option to scale up by selecting the VM disk type and size. And guess what? You can even select the Jenkins release type you want to use - LTS, weekly build or Azure verified - all under your control. Continuous integration experience. In the latest version of our Azure VM Agents plugin, we improved the user experience and added the option to let you to select Managed Disk for disk type (which is currently used extensively on ci.jenknis.io. You no longer need to worry about exceeding the number of VMs on your subscription. Continuous deployment experience. Now, if Azure CLI is not your cup of tea, we released our first plugin to provide continuous deployment support to Azure App Service. The plugin supports all languages Azure App Service supports. We even have a walkthrough here in the brand new Jenkins Hub where you can find all Jenkins on Azure resources. Pipeline readiness. Also, all Azure plugins are and will be pipeline ready. Have you been leveraging our Azure Storage plugin in your Pipeline? So, what’s next? We have a big surprise in store at Jenkins World! :) We are serious about supporting open source and the open source community. Be sure to catch our talk on Azure DevOps open source integrations. See you at Jenkins World 2017! Join the Azure DevOps team at Jenkins World in August, register with the code JWFOSS for a 30% discount off your pass.

This is a guest post by Liam Newman, Technical Evangelist at CloudBees. There are less than three weeks left until Jenkins World 2017. Like last year, I’ll be at the " Ask the Experts" booth to answer questions about all things Jenkins. In preparation, I’ve started a continuing series of quick tutorial videos that answer some of the most common questions I’ve seen asked in the community forums. These are by no means exhaustive - they’re basic answers, which we can build upon. Each video give a takes a simple example, shows how to create a working solution, and includes links in the description to related Jenkins documentation pages. I hope you find them useful. Look for more of them coming soon! Liam will be at the " Ask the Experts" booth at Jenkins World in August. Register with the code JWFOSS for a 30% discount off your pass. Creating Your First Pipeline in Blue Ocean Using a Dockerfile with Jenkins Pipeline Adding Parameters to Jenkins Pipeline Recording Test Results and Archiving Artifacts

This is a guest post by Mark Waite, who maintains the git plugin, the git client plugin, and is a technical evangelist for CloudBees, Inc. While developing the " Intro to Plugin Development" workshop for Jenkins World 2017, I was impressed by the many Jenkins plugin development videos, tutorials, and guides. Here are some of my favorite plugin development topics and links. Plugin tutorial videos Jenkins Online Meetup Plugin Development Part 1 - Basics - Steven Christou and Jesse Glick Jenkins Online Meetup Plugin Development Part 2 - Web UI - Daniel Beck and Tom Fennelly Writing your third plugin - Justin Ryan Jenkins Hackathon session at TNG Technology Consulting - Kohsuke Kawaguchi Plugin tutorial pages Tutorial on jenkins.io Install a Java Development kit, for example AdoptOpenJDK 8 or 11 Install the latest maven release Install your IDE (I like Netbeans, has the Jenkins/Stapler plugin to make plugin creation as easy as menu:File[New Project > Maven > Jenkins Plugin]) More details Many of the Jenkins plugin development topics have dedicated pages of their own, including user interface, plugin testing, and javadoc. User interface UI samples plugin (bars, boxes, buttons, lists, notification, and syntax highlighting) Understanding Jelly Tags from the Jenkins wiki Form Validation from the Jenkins wiki Jelly Form Controls from the Jenkins wiki Jelly Tag Library Reference from jenkins.io DataBoundConstructor in Basic Guide to Jelly usage DataBoundSetter in google groups Testing a plugin Unit test from the Jenkins wiki Jenkins test objects like JenkinsRule and the WithoutJenkins annotation DataBoundConstructor in Basic Guide to Jelly usage DataBoundSetter in google groups Java unit testing tools like Hamcrest and AssertJ (and JenkinsMatchers) Java unit testing rules like TemporaryFolder, Timeout, and DisableOnDebug Java unit testing classes like Assume and Parameterized Java unit testing mock frameworks like mockito and powermock Javadoc Jenkins core javadoc Jenkins plugins javadoc Extension Points List of Jenkins core extension points and all Jenkins extension points Custom build steps Adding a custom build step Actions Jenkins Action and its subtypes Mark will be presenting Intro to Plugin Development at Jenkins World in August. Register with the code JWFOSS for a 30% discount off your pass.

Multiple Jenkins plugins received updates today that fix several security vulnerabilities, including multiple high severity ones. We strongly recommend updating the following plugins as soon as possible: Blue Ocean Pipeline: Groovy Plugin Script Security Plugin Less severe security updates have been released for these plugins: Config File Provider Plugin Datadog Plugin Deploy to container Plugin DRY Plugin Pipeline: Input Step Plugin Static Analysis Utilities Plugin Additionally, the OWASP Dependency-Check Plugin recently also received a security update. For an overview of what was fixed, see the security advisory. Subscribe to the jenkinsci-advisories mailing list to receive important future notifications related to Jenkins security.

This is a guest post by Alyssa Tong, who runs the Jenkins Area Meetup program and is also responsible for Marketing & Community Programs at CloudBees, Inc. There are less than four weeks left until Jenkins World 2017. As usual, Jenkins World would not be complete without the Jenkins projects' "Ask the Experts". If you are new to Jenkins World, the Jenkins project booth will be located on the expo floor where contributors to the project hang out, share demos, and help users via the "Ask the Experts" program. I hope you will be pleasantly surprised at the amount of 1-on-1 learning to be had in the booth! We have a great list of experts who have volunteered to help staff the booth, including many frequent contributors, JAM organizers, and board members: Daniel Beck - Core, security, Jenkins supporting infra and developer supporting infra, project processes and governance Steven Christou - Plugins R. Tyler Croy - Pipeline, Docker, governance Nicolas De Loof - Docker James Dumay - Blue Ocean, Pipeline, Jenkins future Damien Duportal - Docker, Infra/Virtualization, Provisioning Systems (ansible,chef, etc.), Pipeline Tom Fennelly - Blue Ocean, general frontend stuff, general Jenkins stuff Jesse Glick - Core, Pipeline, security, Jenkins dev infra, Mercurial, … Michael Hutterman - DevOps Baptiste Mathus - Governance, infra, Pipeline, HOSTING Michael Neale - Docker, Blue Ocean Oleg Nenashev - Jenkins core, Jenkins administration, remoting Liam Newman - Pipeline, Jenkins 2 James Nord - Maven, plugins Sam Van Oort - Pipeline, performance/scalability, Linux, Docker Chris Orr - Android development, Jenkins dev infra Carlos Sanchez - Docker, Mesos, Kubernetes Bobby Sandell - Gerrit, Declarative Pipeline, core Thorsten Scherler - Blue Ocean, front-end Eric Smalling - Docker, config management (Puppet, some Ansible), VMware solutions, running Jenkins at large scale and general enterprise SDLC Olivier Vernin - Infra, Docker Mark Waite - Git, Git plugin, Git client plugin Owen Mehegan - GitLab plugin Don’t have questions? Stop by anyways to say ‘hello’ and pick up some stickers. If you are an active member of the Jenkins community and/or a contributor, consider taking part in the "Ask the Experts" program. It’s a great opportunity to bond with other contributors and talk with fellow Jenkins users. Join the Jenkins project at Jenkins World in August, register with the code JWFOSS for a 30% discount off your pass.

This is a guest post by Alvin Huang, DevOps Engineer at FireEye. As a security company, FireEye relentlessly protects our customers from cyber attacks. To act quickly on intelligence and expertise learned, the feedback loop from the front lines to features and capabilities in software must be small. Jenkins helps us achieve this by allowing us to build, test, and deploy to our hardware and software platforms faster, so we can stop the bad guys before they reach our customers. More capabilities and functionalities in our product offerings means more applications and systems, which means more software builds and jobs in Jenkins. Within the FaaS (FireEye as a Service) organization, the tens of Jenkins jobs that were manageable manually in the web GUI quickly grew to hundreds of jobs that required more automation. Along the way, we outgrew our old legacy datacenter and were tasked with migrating 150+ Freestyle jobs on an old 1.x Jenkins instance to a newer 2.x instance in the new datacenter in 60 days. Copying Freestyle job XML configuration files to the new server would leave technical debt. Using Freestyle job templates would be better but for complicated jobs that require multiple templates, this would still create large dependency chains that would be hard to trace in the log output. Finally, developers were not excited about having to replicate global changes, such as add an email recipient when a new member joins the team, across tens of jobs manually or using the Configuration Slicer. We needed a way to migrate the jobs in a timely fashion while getting rid of as much technical debt as possible. Jenkins Pipeline to the rescue! In 2.0, Jenkins added the capability to create pipelines as first- class entities. At FireEye, we leveraged many of the features available in pipeline to aid in the migration process including the ability to: create Pipeline as Code in a Jenkinsfile stored in SCM create Jenkins projects automatically when new branches or repos get added with a Jenkinsfile continue jobs after the Jenkins controller or build agent crashes and most importantly, build a Pipeline Shared Library that keeps projects DRY and allows new applications to be on boarded into Jenkins within seconds However, Jenkins Pipeline came with a DSL that our users would have to learn to translate their Freestyle jobs to pipeline jobs. This would be a significant undertaking across multiple teams just to create Jenkins jobs. Instead, the DevOps team identified similarities across all the Freestyle jobs that we were migrating, learned the Jenkins DSL to become SMEs for the organization, and built a shared library of functions and wrappers that saved each Dev/QA engineer hours of time. Below is an example function we created to promote builds in Artifactory: vars/promoteBuild.groovy def call(source_repo, target_repo, build_name, build_number) { stage('Promote to Production repo') { milestone label: 'promote to production' input 'Promote this build to Production?' node { Artifactory.server(getArtifactoryServerID()).promote([ 'buildName' : build_name, 'buildNumber' : build_number, 'targetRepo' : target_repo, 'sourceRepo' : source_repo, 'copy' : true, ]) } } def call(source_repo, target_repo) { buildInfo = getBuildInfo() call(source_repo, target_repo, buildInfo.name, buildInfo.number) } Rather than learning the Jenkins DSL and looking up how the Artifactory Plugin worked in Pipeline, users could easily call this function and pass it parameters to do the promotion work for them. In the Shared Library, we can also create build wrappers of opinionated workflows, that encompasses multiple functions, based on a set of parameters defined in the Jenkinsfile. In addition to migrating the jobs, we also had to migrate the build agents. No one knew the exact list of packages, versions, and build tools installed on each build server, so rebuilding them would be extremely difficult. Rather than copying the VMs or trying to figure out what packages were on the build agents, we opted to use Docker to build containers with all dependencies needed for an application. I hope you will join me at my Jenkins World session: Codifying the Build and Release Process with a Jenkins Pipeline Shared Library, as I deep dive into the inner workings of our Shared Pipeline Library and explore how we integrated Docker into our CI/CD pipeline. Come see how we can turn a Jenkinsfile with just a set of parameters like this: Jenkinsfile standardBuild { machine = 'docker' dev_branch = 'develop' release_branch = 'master' artifact_apttern = '*.rpm' html_pattern = [keepAll: true, reportDir: '.', reportFiles: 'output.html', reportName: 'OutputReport'] dev_repo = 'pipeline-examples-dev' prod_repo = 'pipeline-examples-prod' pr_script = 'make prs' dev_script = 'make dev' release_script = 'make release' } and a Dockerfile like this: Dockerfile FROM faas/el7-python:base RUN yum install -y python-virtualenv \ rpm-build && \ yum clean all Into a full Jenkins Pipeline like this: As we look ahead at FireEye, I will explore how the Shared Library sets us up for easier future migrations of other tools such as Puppet, JIRA, and Artifactory, and easier integration with new tools like Openshift. I will also cover our strategies for deployments and plans to move to Declarative Pipeline. Alvin will be presenting more on this topic at Jenkins World in August, register with the code JWFOSS for a 30% discount off your pass.

I am pleased to announce Microsoft PowerShell support for Jenkins Pipeline! As of Durable Task 1.14 and Pipeline Nodes and Processes Plugin 2.12, you will now be able to run Microsoft PowerShell scripts directly in your Jenkins Pipeline projects. This blog post covers the basics of getting started with Microsoft PowerShell in Pipeline and provides some basic examples. Introduction to Microsoft PowerShell PowerShell is Microsoft’s open source and cross platform command line shell, as well as an automation and configuration tool/framework which has a broad user base. PowerShell can be used to perform common system administration tasks in Windows, macOS, and Linux environments. It can also be used as a general purpose scripting language. Now that Jenkins Pipeline supports PowerShell, you can enjoy the rich set of features in PowerShell for your daily DevOps work. Before diving into using PowerShell in your Pipeline, I recommend reading the Windows PowerShell Reference as well as the PowerShell Team Blog for an introduction to PowerShell features, utilities, and as a quick look into the PowerShell language. Microsoft also has an active PowerShell community on GitHub, which I highly recommend visiting to submit feature requests and bug reports as you see fit. Jenkins Pipeline currently supports Microsoft PowerShell 3.0 or higher, so also be sure to check which version of PowerShell is installed on your system in order to take advantage of PowerShell in your Pipeline. Please note that we recommend that you upgrade to the latest stable version of PowerShell available, which as of this writing is version 5.1.14393. The powershell step node { powershell 'Write-Output "Hello, World!"' } Using Microsoft PowerShell in Pipeline Writing PowerShell code as part of your pipeline is incredibly simple. The step that you will use is simply powershell, and it includes the same optional parameters as the Windows Batch ( bat) step, including: returnStdout: Returns the standard output stream with a default encoding of UTF-8 (alternative encoding is optional) returnStatus: Returns the exit status (integer) of the PowerShell script Examples Capture exit status of a PowerShell script node { def status = powershell(returnStatus: true, script: 'ipconfig') if (status == 0) { // Success! } } Capture and print the output of a PowerShell script node { def msg = powershell(returnStdout: true, script: 'Write-Output "PowerShell is mighty!"') println msg } Which streams get returned when I use returnStdout? Until the release of PowerShell 5, there were five distinct output streams. PowerShell 5 introduced a sixth stream for pushing "informational" content, with the added benefit of being able to capture messages sent to Write-Host. Each row of the following table describes a PowerShell stream along with the corresponding Cmdlet used for writing to the stream for that particular row. Please keep in mind that stream 6 and associated cmdlets either do not exist or exhibit alternate behavior in versions of PowerShell earlier than version 5. Stream Description Cmdlet 1 Output stream (e.g. stdOut) Write-Output 2 Error stream (e.g. stdErr) Write-Error 3 Warning stream Write-Warning 4 Verbose stream Write-Verbose 5 Debug stream Write-Debug 6 Information stream Write-Information (or Write-Host with caveats) If you are using the returnStdout option of the powershell Pipeline step then only stream 1 will be returned, while streams 2-6 will be redirected to the console output. For example: Write to all available streams and return the standard output node { def stdout = powershell(returnStdout: true, script: ''' # Enable streams 3-6 $WarningPreference = 'Continue' $VerbosePreference = 'Continue' $DebugPreference = 'Continue' $InformationPreference = 'Continue' Write-Output 'Hello, World!' Write-Error 'Something terrible has happened!' Write-Warning 'Warning! There is nothing wrong with your television set' Write-Verbose 'Do not attempt to adjust the picture' Write-Debug 'We will control the horizontal. We will control the vertical' Write-Information 'We can change the focus to a soft blur or sharpen it to crystal clarity.' ''') println stdout } Console output: [Pipeline] { [Pipeline] powershell [TestStreams] Running PowerShell script \workspace\TestStreams@tmp\durable-4d924c2d\powershellScript.ps1 : Something terrible has happened! At \workspace\TestStreams@tmp\durable-4d924c2d\powershellMain.ps1:2 char:1 + & ' \workspace\TestStreams@tmp\durable-4d924c ... + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : NotSpecified: (:) [Write-Error], WriteErrorException + FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorException,powershellScript.ps1 Warning! There is nothing wrong with your television set Do not attempt to adjust the picture We will control the horizontal. We will control the vertical We can change the focus to a soft blur or sharpen it to crystal clarity. Hello, World! [Pipeline] } [Pipeline] // node [Pipeline] End of Pipeline ERROR: script returned exit code 1 Finished: FAILURE Note that "Hello, World!" gets printed last even though it is the first output statement in my script. Another interesting aspect of this example is that the powershell step failed, which ultimately caused the job to fail. The failure in this example is due to the PowerShell error stream being non-empty, which therefore caused the step to result in a non-zero exit status. However, as you will soon discover, there are a variety of causes for a failing powershell step. What causes a failing exit status? When you execute a powershell step, it may produce a non-zero exit code and fail your pipeline build. This is very similar to other shell steps with some interesting caveats. Your powershell step may produce a failing exit status in the following instances: Something in your PowerShell script has thrown an exception Your PowerShell script explicitly calls exit with a non-zero exit code Your PowerShell script calls a native application that produces a non-zero $LastExitCode $LastExitCode is an automatic variable that is set after executing a native application Your PowerShell script results in a non-empty error stream (with or without throwing an exception) Overriding the exit status behavior of your powershell step can be achieved by explicitly exiting from your script as long as the failure was not caused by an unhandled exception. For example: Unavoidable failure caused by an unhandled exception node { powershell ''' throw 'Error! Problem Exists Between Keyboard And Chair' exit 0 # Unreachable code ''' } Failed step caused by a non-empty error stream node { powershell ''' Write-Error 'Error! Problem Exists Between Keyboard And Chair' ''' } Failure prevented by an explicit exit node { powershell ''' Write-Error 'Error! Problem Exists Between Keyboard And Chair' exit 0 ''' } Scripts vs. Cmdlets A Cmdlet is a small lightweight utility written in either C#, and compiled, or written in PowerShell directly. Depending on what your goal is in your pipeline you can make use of Cmdlets directly in your pipeline code, call a self contained PowerShell script, or some mixture of the two. If your strategy is to keep each powershell step as short and succinct as possible then it may make sense for you to write a library of Cmdlets, but if you have monolithic scripts then it may make sense for you to call those scripts directly from your pipeline. The choice is entirely up to you, as both scenarios are supported. Thanks for reading, and have fun! I sincerely hope that this post has encouraged you to try using PowerShell in your Jenkins Pipeline. Please do not hesitate to file an issue against the durable-task plugin on JIRA if you have discovered any problem that you suspect is related to the powershell step. For general PowerShell related issues or inquiries please route your questions to the PowerShell community.