Shulou(Shulou.com)05/31 Report--

Editor to share with you what the improvement of the Jenkins visualization phase view is, I believe most people do not know much about it, so share this article for your reference, I hope you can learn a lot after reading this article, let's go to know it!

Improvement of Jenkins Visualization Phase View

In addition to success or failure, the pipeline has a state in between.

Some recently released changes have given pipeline editors new tools to improve pipeline visualization in Blue Ocean, and there is a high-profile work order JENKINS-39203, which causes all phases to be set to unstable when the build result of the pipeline is unstable. This flaw makes it impossible to quickly identify why the build is unstable, making it necessary for users to check the full log and Jenkinsfile to figure out what's going on.

To fix this problem, we introduced a new pipeline API to add additional result information for a single pipeline step. Visualization tools like Blue Ocean use this new API when deciding how to display the phase. Steps like junit can only set the entire build result, and now you can set the step-level result information through the new API. We created new steps unstable and warnError so that pipeline editors can still take advantage of the new API in more complex scenarios.

The important fixes involved in this issue are included in the following plug-ins, which require Jenkins 2.138.4 and later:

Pipeline: API 2.34

Pipeline: Basic Steps 2.18 (need to update synchronously to Pipeline: Groovy 2.70)

Pipeline: Graph Analysis 1.10

Pipeline: Declarative 1.3.9

Blue Ocean 1.17.0

Here is a screenshot of a pipeline using the unstable step in Blue Ocean, which only identifies the failed phase as unstable:

Examples

Here are some examples of how to use this feature in your pipeline:

Use the new step warnError to catch errors and mark builds and phases as unstable. WarnError only needs a parameter of a string to output as a log when an error is caught. When warnError catches an error, it logs the message as well as the error and sets the results of the build and phase to unstable. The effect is as follows:

WarnError ('Script failed') {sh ('false')}

Use the new step unstable to set the build and phase results to unstable. You can use this step to directly replace currentBuild.result = 'UNSTABLE', which is useful when warnError is not flexible enough. The step unstable requires only one string parameter, which is used as a message when the step is run. The methods used are as follows:

Try {sh ('false')} catch (ex) {unstable (' Script failed')}

JUnit Plugin: update to version 1.28 or later so that step junit can directly set this phase to be unstable.

Warnings Next Generation Plugin: update to version 5.2.0 or later so that step publishIssues and recordIssues can directly set this phase to be unstable.

Other plug-ins: if your pipeline is marked as unstable by steps in other plug-ins, please (after checking that there are no duplicates) submit a new issue to the component, clearly describing which step is problematic and the environment in which the problem occurs, and add a link to the developer area of the article so that maintainers know how to solve the problem.

Limitation

If you do not migrate to the unstable or warnError step, or if you do not upgrade the plug-in to integrate to the new API to set the build state, then even if the build is unstable, Blue Ocean will not show any phase as unstable.

Even after these changes, currentBuild.result continues to override only the build state. Unfortunately, because currentBuild is implemented as a global variable, it cannot be allowed to set step or phase-level results, which means it does not have any step-level context to use the new API.

Pipeline Stage View Plugin has not been upgraded to use this new API, so these changes will not be reflected in the visualization it provides.

History

The Jenkins pipeline step can be completed in two ways: succeed and return a result (possibly null), or fail and throw an exception. When a step fails and an exception is thrown, the exception runs through the pipeline until another step or Groovy code catches it, or it reaches the top level of the pipeline and causes the pipeline to fail. Depending on the type of exception thrown, the pipeline may not end up failing (for example, terminated in some cases). Based on the way exceptions are propagated, tools like Blue Ocean can easily identify which steps (and phases) have failed.

In order for the pipeline to interact with the corresponding Jenkins API, it is also necessary for the pipeline build to modify the build results during the build. For others, this allows the pipeline to use build steps and projects that were originally part of a free-style task.

In some cases, a pipeline step needs to be able to complete successfully so that the pipeline can continue to execute normally, but for this reason it is possible to mark some kind of error, so that the step where the error occurred can be identified during visualization, even if it does not fail completely. A good example is the junit step. This step focuses on specific test results, and if there are any errors, the entire build result is marked as unstable. This behavior is problematic for visualization tools like BlueOcean because the step is successful and cannot programmatically override the end result associated with the step.

Looking at JENKINS-39203 again, we see that there are two basic options for visualization. Because some steps cause the build to become unstable, the overall build result is unstable, or all the steps are completed successfully to show that they are unstable; or because we have no way to set the build results related to a particular step, they may appear to be successful. Finally, the first option is selected.

In order to solve this problem, some users try to handle exceptions by throwing exceptions and adding code blocks such as try/catch in the phase, so that Blue Ocean can use these exceptions to mark the results of the steps and phases as the desired state, and after catching the exception, the pipeline can continue to execute normally. This approach is not easy to understand, fragile, and cannot be used in a declarative assembly line.

The above is all the content of the article "what is the improvement of Jenkins Visualization Phase View?" Thank you for reading! I believe we all have a certain understanding, hope to share the content to help you, if you want to learn more knowledge, welcome to follow the industry information channel!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.