zowe / jenkins-library Goto Github PK

View Code? Open in Web Editor NEW

51.0 5.0 39.0 2.98 MB

Jenkins Pipeline Library

Home Page: https://zowe.github.io/jenkins-library

License: Eclipse Public License 2.0

Groovy 99.84% Batchfile 0.07% Shell 0.08%

jenkins-library's Introduction

Jenkins Pipeline Shared Library

This repository holds shared library for Jenkins Pipeline

Import Library

The Jenkins library requires sophisticated operation on Jenkins objects, which requires to be setup as Global Pipeline Libraries to avoid extra In-process Script Approval.

Configure Jenkins Pipeline Job

In The Manage Jenkins - Configure System section, find Global Pipeline Libraries and click ADD.
- Give the library a name, for example, jenkins-library. Set Default version to master.
- For Retrieval method, choose Modern SCM.
  - For Source Code Management section, choose GitHub.
  - Configure github connection to this repository

Import Library in Jenkinsfile

If you didn't check Load implicitly when configuring the job, you need to use @Library to import it.

In your Jenkinsfile, you can add def lib = library("jenkins-library").org.zowe.jenkins_shared_library on top of the file to import library.

Then you can use any classes/methods defined in the library. For example:

github = lib.scm.GitHub.new(this)
github.init([...])
github.commit('my test')

Run Tests

To start test, run gradle command gradle test.

Generate Documentation

Run gradle command gradle groovydoc to generate documentation.

Relase Process Design

All below scenarios are based on master version v2.3.4 as example, timestamp string example is 20190101000000.

Things We Want to Do

Allow every branches to publish artifacts for debugging purpose.
Release is only performed when we want to, so it's always started manually.

Special Notes

The release stage doesn't have option to choose MINOR/MAJOR/SPECIFIC version bump. Those works should be handled in GitHub with Pull Requests.
The relase stage doesn't have manual approval option. We assume everything pushed into master branch is for release purpose and have been reviewed by Pull Request reviewers.

Release Options

For each pipeline, we have 2 build parameters are only available to branches which can do a release:
- Perform Release: boolean, default is false.
- Pre-Release String: string, default is empty. This parameter will only be used if Perform Release is true. This parameter is required if the release is not happened on master or v?.x/master branch.
By default, only master, v?.x/master, staging and v?.x/staging branches can do a release. This can be changed by pipeline.addReleaseBranches(...branches) or pipeline.setReleaseBranches(...branches).
For NPM packages, each branch can have a npm publish tag name when performaing release build. By default, master's tag is latest, staging's tag is dev. For branches do not have publish tag defined, or branches is not in release build, npm publish will use default snapshot tag name, and the version will have normalized branch name included. For example, staging branch non-release build will generate a version v2.3.4-staging-snapshot.20190101000000 release on snapshot npm tag. staging branch release build will generate a version v2.3.4-dev.20190101000000 release on dev tag. And a branch feature/lts build will generate a version v2.3.4-feature-lts-snapshot.20190101000000 release on snapshot tag.
For pax/zip packages, each branch can also have a release tag name. By default, master's tag is 'snapshot'. If it's not defined, artifactory publish will use branch name as tag name. For example, master non-release build will publish artifact to libs-snapshot-local/org/zowe/<component>/2.3.4-snapshot/ and release build will publish to libs-release-local/org/zowe/<component>/2.3.4/. staging non-release build will publish artifact to libs-snapshot-local/org/zowe/<component>/2.3.4-staging/ and release build will publish to libs-release-local/org/zowe/<component>/2.3.4-rc1/, the rc1 is the pre-release string which is required.

Pipeline Build Scenarios

Scenario #1
- Build on master with default parameter values (Perform Release = false, Pre-Release String = empty)
  - for npm package, it will be published to npm-local-release as v2.3.4-snapshot-master.20190101000000 with npm tag snapshot.
  - for pax/zip(gradle) package, it will be published to libs-snapshot-local/org/zowe/<component>/2.3.4-snapshot/ as <component>-2.3.4-snapshot.20190101000000.(pax|zip).
- No github tag will be created.
- No version bump will be performed on GitHub.
Scenario #2
- Build on master with (Perform Release = true, Pre-Release String = beta.1)
  - for npm package, it will be published to npm-local-release as v2.3.4-beta.1 with npm tag snapshot.
  - for pax/zip(gradle) package, it will be published to libs-release-local/org/zowe/<component>/2.3.4/ as <component>-2.3.4-beta.1.(pax|zip).
- Github tag v2.3.4-beta.1 will be created.
- No version bump will be performed on GitHub after release.
Scenario #3
- Build on master with (Perform Release = true, Pre-Release String = empty)
  - for npm package, it will be published to npm-local-release as v2.3.4 with npm default tag latest.
  - for pax/zip(gradle) package, it will be published to libs-release-local/org/zowe/<component>/2.3.4/ as <component>-2.3.4.(pax|zip).
- Github tag v2.3.4 will be created.
- A PATCH level version bump will be performed on GitHub. This is to avoid release the same version again. So after version bump, master has version of 2.4.0, and a commit can be seen from github commit history. This commit should be merged/cherry-picked back to staging.
Scenario #dev-1
- Build on staging which IS a release branch with default parameter values (Perform Release = false, Pre-Release String = empty)
  - for npm package, it will be published to npm-local-release as v2.3.4-staging-snapshot.20190101000000 with npm tag snapshot.
  - for pax/zip(gradle) package, it will be published to libs-snapshot-local/org/zowe/<component>/2.3.4-staging/ as <component>-2.3.4-staging.20190101000000.(pax|zip).
- No github tag will be created.
- No version bump will be performed on GitHub.
Scenario #dev-2
- Build on staging which IS a release branch with default parameter values (Perform Release = true, Pre-Release String = rc.1)
  - for npm package, it will be published to npm-local-release as v2.3.4-rc.1 with npm tag dev.
  - for pax/zip(gradle) package, it will be published to libs-snapshot-local/org/zowe/<component>/2.3.4-staging/ as <component>-2.3.4-staging.20190101000000.(pax|zip).
- No github tag will be created.
- No version bump will be performed on GitHub after release.
Scenario #dev-3
- Build on staging which IS a release branch with default parameter values (Perform Release = true, Pre-Release String = empty)
- Build will be rejected because pre-release string is empty.
Typical Scenario
- A NPM project has latest, dev, v1-latest and v1-dev tags. v1 is a LTS version, current master is on v2.3.4.
- There are 4 branches can do a release, the branch-tag mappings are:
  - master - latest
  - staging - dev
  - v1.x/master - v1-latest
  - v1.x/staging - v1-dev

Release Scenarios

Release v2.3.4-rc.1
- Build staging with (Perform Release = true, Pre-Release String = rc.1).
- Or build master with (Perform Release = true, Pre-Release String = rc.1), not suggested.
Release v2.3.4
- Build master with (Perform Release = true, Pre-Release String = empty).
Release v2.4.0
- Make a commit on staging to upgrade version to 2.4.0.
- Build staging with (Perform Release = true, Pre-Release String = rc.1), we should have v2.4.0-rc.1.
- Create a Pull Request to merge staging into master. After merged, master should have a version definition of 2.4.0 instead of 2.3.4.
- build master with (Perform Release = true, Pre-Release String = empty), we should have v2.4.0.

jenkins-library's People

Contributors

Stargazers

Watchers

jenkins-library's Issues

Option to add timestamps to console log when creating new stage

timestamper plugin provides timestamps {}

Create Support to create/close Github pull request

This is essential to automate the updating of docs site and zowe.org.

Research on overwrite default archiveArtifacts function to upload to Zowe Artifactory

zFernand0 1 hour ago •
Member
@jackjia-ibm, It'd be nice if we could overload the archiveArtifacts method to upload files to the zowe.jfrog.io site, (maybe on a default zowe/artifacts location, or the user-specified location in artifactory)

Full build information is required to promote a build

To fully migrate away from the function /vars/getArtifactoryBuildInfoByAPI.groovy, we need a similar method in class library.

.tar.gz artifact will be uploaded as tar.[version]-[release].gz

name of file has got spoiled:
sample-angular-app.tar-1.1.0-staging-16-20190605160624.gz instead of sample-angular-app.tar-1.1.0-staging-16-20190605160624.tar.gz

Bug - _sendEmailNotification may raise groovy.lang.MissingPropertyException: No such property: user for class:

If the stage is aborted with timeout, the pipeline will show an exception:

groovy.lang.MissingPropertyException: No such property: user for class: org.jenkinsci.plugins.workflow.steps.TimeoutStepExecution$ExceededTimeout
	at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.unwrap(ScriptBytecodeAdapter.java:53)
	at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.getProperty(ScriptBytecodeAdapter.java:458)
	at com.cloudbees.groovy.cps.sandbox.DefaultInvoker.getProperty(DefaultInvoker.java:39)
	at com.cloudbees.groovy.cps.impl.PropertyAccessBlock.rawGet(PropertyAccessBlock.java:20)
	at org.zowe.jenkins_shared_library.pipelines.base.Pipeline._sendEmailNotification(file:/var/jenkins_home/jobs/zowe-install-test/branches/new-install-script-version/builds/79/libs/jenkins-library/src/org/zowe/jenkins_shared_library/pipelines/base/Pipeline.groovy:852)
	at org.zowe.jenkins_shared_library.pipelines.base.Pipeline.endBase(file:/var/jenkins_home/jobs/zowe-install-test/branches/new-install-script-version/builds/79/libs/jenkins-library/src/org/zowe/jenkins_shared_library/pipelines/base/Pipeline.groovy:770)
	at org.zowe.jenkins_shared_library.pipelines.base.Pipeline.endBase(file:/var/jenkins_home/jobs/zowe-install-test/branches/new-install-script-version/builds/79/libs/jenkins-library/src/org/zowe/jenkins_shared_library/pipelines/base/Pipeline.groovy:784)
	at org.zowe.jenkins_shared_library.pipelines.generic.GenericPipeline.endGeneric(file:/var/jenkins_home/jobs/zowe-install-test/branches/new-install-script-version/builds/79/libs/jenkins-library/src/org/zowe/jenkins_shared_library/pipelines/generic/GenericPipeline.groovy:648)
	at org.zowe.jenkins_shared_library.pipelines.generic.GenericPipeline.end(file:/var/jenkins_home/jobs/zowe-install-test/branches/new-install-script-version/builds/79/libs/jenkins-library/src/org/zowe/jenkins_shared_library/pipelines/generic/GenericPipeline.groovy:657)
	at WorkflowScript.run(WorkflowScript:592)
	at ___cps.transform___(Native Method)
	at com.cloudbees.groovy.cps.impl.PropertyishBlock$ContinuationImpl.get(PropertyishBlock.java:74)
	at com.cloudbees.groovy.cps.LValueBlock$GetAdapter.receive(LValueBlock.java:30)
	at com.cloudbees.groovy.cps.impl.PropertyishBlock$ContinuationImpl.fixName(PropertyishBlock.java:66)
	at sun.reflect.GeneratedMethodAccessor72.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at com.cloudbees.groovy.cps.impl.ContinuationPtr$ContinuationImpl.receive(ContinuationPtr.java:72)
	at com.cloudbees.groovy.cps.impl.ConstantBlock.eval(ConstantBlock.java:21)
	at com.cloudbees.groovy.cps.Next.step(Next.java:83)
	at com.cloudbees.groovy.cps.Continuable$1.call(Continuable.java:174)
	at com.cloudbees.groovy.cps.Continuable$1.call(Continuable.java:163)
	at org.codehaus.groovy.runtime.GroovyCategorySupport$ThreadCategoryInfo.use(GroovyCategorySupport.java:129)
	at org.codehaus.groovy.runtime.GroovyCategorySupport.use(GroovyCategorySupport.java:268)
	at com.cloudbees.groovy.cps.Continuable.run0(Continuable.java:163)
	at org.jenkinsci.plugins.workflow.cps.SandboxContinuable.access$101(SandboxContinuable.java:34)
	at org.jenkinsci.plugins.workflow.cps.SandboxContinuable.lambda$run0$0(SandboxContinuable.java:59)
	at org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.GroovySandbox.runInSandbox(GroovySandbox.java:108)
	at org.jenkinsci.plugins.workflow.cps.SandboxContinuable.run0(SandboxContinuable.java:58)
	at org.jenkinsci.plugins.workflow.cps.CpsThread.runNextChunk(CpsThread.java:174)
	at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup.run(CpsThreadGroup.java:332)
	at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup.access$200(CpsThreadGroup.java:83)
	at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup$2.call(CpsThreadGroup.java:244)
	at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup$2.call(CpsThreadGroup.java:232)
	at org.jenkinsci.plugins.workflow.cps.CpsVmExecutorService$2.call(CpsVmExecutorService.java:64)
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
	at hudson.remoting.SingleLaneExecutorService$1.run(SingleLaneExecutorService.java:131)
	at jenkins.util.ContextResettingExecutorService$1.run(ContextResettingExecutorService.java:28)
	at jenkins.security.ImpersonatingExecutorService$1.run(ImpersonatingExecutorService.java:59)
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
	at java.lang.Thread.run(Thread.java:748)

The line with error is src/org/zowe/jenkins_shared_library/pipelines/base/Pipeline.groovy:

            if (buildStatus == "ABORTED") {
                emailText = "Aborted by ${((FlowInterruptedException) firstFailingStage.exception).causes[0]?.user}"
            } else {

Add releaseRegistry from publishRegistry

So the user can have an option to specify a different release npm registry for protected branches other than regular publish registry.

Backup docker image before pushing

Docker image is usually built based on base image from other team. If those base image has any changes, or have changes in apt update, we will have a new image even if nothing is changed in Dockerfile. So to make sure everything works ok. it's safe to backup the image will be overwritten before pushing/updating.

Apply default values for some pre-defined services

Currently constants defined in org.zowe.jenkins_shared_library.Constants, for each pipeline have to define them explicitly when consuming them.

Change those to default values so pipelines don't have to define them everywhere.

Clarify "packaging" default behavior

Currently, the default "packaging" operation will attempt to ship code and archive it in a PAX. This operation is fully configurable via the operation: { "echo 'my steps' " } parameter, but the default behavior may confuse adopters.

Perform formal release on non-master branch will bump version on master branch

Add support to sign and generate hash of a package

This is part of automating the publishing part.

CpsClosure2 warning on the build log

With upgrade of plugin, the build log now shows a lot of warnings:

expected to call org.zowe.jenkins_shared_library.pipelines.base.models.Stage.execute but wound up catching org.jenkinsci.plugins.workflow.cps.CpsClosure2.call; see: https://jenkins.io/redirect/pipeline-cps-method-mismatches/

Seems this warning doesn't affect the build, but it should be investigated.

Add option to allow a pipeline doesn't have test stage at all

Some pipelines have special purpose and doesn't have meaningful test stage. Add an option to skip the mandatory test stage check for publish/release stage.

Create option commitsAllowed for GenericPipeline - for LF jenkins

Problem to solve

To mitigate the permission issue on LF Jenkins, we need a new way to trigger build on Jenkins manually.

Solution

Introduce commitsAllowed as String[] and with value of RegExp strings. This property will defines what commit messages could trigger a build.

If the value is empty List or null, the build will be triggered by default settings for every commit,
If the value is not empty, the build will check the changes list and see if the last commit matches the pre-defined pattern.
If commit can also have customized information for build parameters, and one line for each parameter.
Pipeline should read through the commit message line by line, skip the first line which we used to match the commitsAllowed and then see if other lines match pattern of key=value. key should be string like [a-zA-Z0-9 \-_] which are characters we usually used to define build parameters, value could be any value to the end of the line.
If the user want to start another test, they must push another commit,
This check can be a new stage automatically added in GenericPipeline setupGeneric method, it has to happen after the code base is checked out.

Example

For zowe-install-test pipeline, define the pipeline commitsAllowed to be ['\[zowe-install-test\]']. There is no zowe-install-test build be triggered by default due to this setting. To start a manual test, run this command:

git commit -s --allow-empty -m "[zowe-install-test]" -m "TEST_SERVER=marist-2" -m "ZOWE_ARTIFACTORY_PATTERN =https://zowe.jfrog.io/......" -m "ZOWE_ARTIFACTORY_BUILD="
git push

When pipeline is kicked off by this commit, the pipeline matches pattern [zowe-install-test] and will resolve the build parameters, in this example, TEST_SERVER, ZOWE_ARTIFACTORY_PATTERN , and ZOWE_ARTIFACTORY_BUILD value, and then start the build.

Potential Issues

params.[build-parameter] is available all the time, but with this approach, the value of params.[build-parameter] is not trustworthy because it could be changed by the setup step.

DockerPipelineMultibranchPipelineTest failed with not be able to find the docker tags

Failed

DockerPipelineMultibranchPipelineTest.testCRelease

Failing for the past 4 builds (Since Failed#4 )
Took 1 min 10 sec.
add description

Error Message

java.lang.AssertionError: Tags
Expected: a collection containing "docker-v0.0.18"
     but: mismatches were: [was "v1.0.246", was "v1.0.248", was "v1.0.249", was "v1.0.251", was "v1.0.252", was "v1.0.254", was "v1.0.255", was "v1.0.257", was "v1.0.258", was "v1.0.260", was "v1.0.261", was "v1.0.263", was "v1.0.264", was "v1.0.266", was "v1.0.267", was "v1.0.269", was "v1.0.270", was "v1.0.272", was "v1.0.273", was "v1.0.275", was "v1.0.276", was "v1.0.278", was "v1.0.279", was "v1.0.281", was "v1.0.282", was "v1.0.284", was "v1.0.285", was "v1.0.287", was "v1.0.288", was "v1.0.290"]

Stacktrace

java.lang.AssertionError: Tags
Expected: a collection containing "docker-v0.0.18"
     but: mismatches were: [was "v1.0.246", was "v1.0.248", was "v1.0.249", was "v1.0.251", was "v1.0.252", was "v1.0.254", was "v1.0.255", was "v1.0.257", was "v1.0.258", was "v1.0.260", was "v1.0.261", was "v1.0.263", was "v1.0.264", was "v1.0.266", was "v1.0.267", was "v1.0.269", was "v1.0.270", was "v1.0.272", was "v1.0.273", was "v1.0.275", was "v1.0.276", was "v1.0.278", was "v1.0.279", was "v1.0.281", was "v1.0.282", was "v1.0.284", was "v1.0.285", was "v1.0.287", was "v1.0.288", was "v1.0.290"]
	at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:18)
	at org.junit.Assert.assertThat(Assert.java:956)
	at org.junit.Assert$assertThat.callStatic(Unknown Source)
	at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallStatic(CallSiteArray.java:55)
	at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callStatic(AbstractCallSite.java:196)
	at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callStatic(AbstractCallSite.java:224)
	at DockerPipelineMultibranchPipelineTest.testCRelease(DockerPipelineMultibranchPipelineTest.groovy:146)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
	at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
	at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
	at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
	at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
	at org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.runTestClass(JUnitTestClassExecutor.java:106)
	at org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:58)
	at org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:38)
	at org.gradle.api.internal.tasks.testing.junit.AbstractJUnitTestClassProcessor.processTestClass(AbstractJUnitTestClassProcessor.java:66)
	at org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
	at org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
	at org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
	at org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
	at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
	at org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:117)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
	at org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
	at org.gradle.internal.remote.internal.hub.MessageHubBackedObjectConnection$DispatchWrapper.dispatch(MessageHubBackedObjectConnection.java:155)
	at org.gradle.internal.remote.internal.hub.MessageHubBackedObjectConnection$DispatchWrapper.dispatch(MessageHubBackedObjectConnection.java:137)
	at org.gradle.internal.remote.internal.hub.MessageHub$Handler.run(MessageHub.java:404)
	at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:63)
	at org.gradle.internal.concurrent.ManagedExecutorImpl$1.run(ManagedExecutorImpl.java:46)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
	at org.gradle.internal.concurrent.ThreadFactoryImpl$ManagedThreadRunnable.run(ThreadFactoryImpl.java:55)
	at java.lang.Thread.run(Thread.java:748)

The error could be caused by there are too many testing tags created for the repository and GitHub doesn't list the tags by reversed date time sequence. Do the docker- tags are not listed in the first response of API.

To fix this, will need to either cleanup the old tags or fetching all the tags to compare.

Allow to specify branch options when running SonarCube scan

SonarCloud supports branch scanning, the lib should allow to publish branch info if the server supports.

Publish POM updates for Gradle/Maven build

Add option to catch-all on Pax packaging

Add support to publish OpenClover coverage report

It relies on plugin: https://wiki.jenkins.io/display/JENKINS/Clover+Plugin

Example pipeline code:

  step([
    $class: 'CloverPublisher',
    cloverReportDir: 'target/site',
    cloverReportFileName: 'clover.xml',
    healthyTarget: [methodCoverage: 70, conditionalCoverage: 80, statementCoverage: 80], // optional, default is: method=70, conditional=80, statement=80
    unhealthyTarget: [methodCoverage: 50, conditionalCoverage: 50, statementCoverage: 50], // optional, default is none
    failingTarget: [methodCoverage: 0, conditionalCoverage: 0, statementCoverage: 0]     // optional, default is none
  ])

      timeout(time: 1, unit: 'HOURS') {
        def qg = waitForQualityGate()
        if (qg.status != 'OK') {
          error "Pipeline aborted due to quality gate failure: ${qg.status}"
        }
      }

New utility function to parse version as artifact path

Few scenarios of when we define a dependency of 'explorer-jes':

with version '0.0.10', the artifact path we are looking at is 'lib-release-local/org/zowe/explorer-jes/0.0.10/explorer-jes-0.0.10.pax'
with version '~0.0.10', the artifact path we are looking at is 'lib-snapshot-local/org/zowe/explorer-jes/0.0.-STAGING/explorer-jes-0.0.-STAGING-*.pax'
with version '^0.0.10', the artifact path we are looking at is 'lib-snapshot-local/org/zowe/explorer-jes/0.-STAGING/explorer-jes-0.-STAGING-*.pax'
with version '0.0.10-MY-BRANCH', the artifact path we are looking at is 'lib-snapshot-local/org/zowe/explorer-jes/0.0.10-MY-BRANCH/explorer-jes-0.0.10-MY-BRANCH-*.pax'
etc.

Push commit on library master will trigger all Jenkins builds

Raise warning if cannot determine publish registry

At line https://github.com/zowe/jenkins-library/blob/master/src/org/zowe/jenkins_shared_library/pipelines/nodejs/NodeJSPipeline.groovy#L300:

pipeline.steps.echo "- ${pipeline.publishRegistry.scope ? '@' + pipeline.publishRegistry.scope + ':' : ''}${pipeline.publishRegistry.registry}"

If pipeline.publishRegistry.registry is empty, it will show as null in the console log.

It is possible to combine multiple pipelines?

Hi,

It is possible to combine NodeJs Pipeline and Docker Pipeline in the same JenkinsFile to run sequential in the same Pipeline ?

Many thanks!

SSHPASS=**** sshpass -e ssh -tt -o StrictHostKeyChecking=no ****@river.zowe.org rm -fr /zaas1/zowe-install-packaging-master-*
Warning: Permanently added 'river.zowe.org,37.58.118.251' (ECDSA) to the list of known hosts.
Permission denied (publickey,keyboard-interactive).

Example builds:

https://wash.zowe.org:8443/job/explorer-mvs/job/master/57/console
https://wash.zowe.org:8443/job/zowe-install-packaging/job/master/709/console
https://wash.zowe.org:8443/job/zowe-install-packaging/view/change-requests/job/PR-488/lastSuccessfulBuild/console