jenkins-library | Jenkins Pipeline Library | Continous Integration library

by zowe Groovy Version: Current License: EPL-2.0

X-Ray Key Features Code Snippets Community Discussions(3)Vulnerabilities Install Support

kandi X-RAY | jenkins-library Summary

jenkins-library is a Groovy library typically used in Devops, Continous Integration, Jenkin applications. jenkins-library has no bugs, it has no vulnerabilities, it has a Weak Copyleft License and it has low support. You can download it from GitHub.

Jenkins Pipeline Library

Support

Quality

Security

License

Reuse

Support

jenkins-library has a low active ecosystem.

It has 38 star(s) with 26 fork(s). There are 6 watchers for this library.

It had no major release in the last 6 months.

There are 12 open issues and 21 have been closed. On average issues are closed in 45 days. There are 1 open pull requests and 0 closed requests.

It has a neutral sentiment in the developer community.

The latest version of jenkins-library is current.

Quality

jenkins-library has 0 bugs and 0 code smells.

Security

jenkins-library has no vulnerabilities reported, and its dependent libraries have no vulnerabilities reported.

jenkins-library code analysis shows 0 unresolved vulnerabilities.

There are 0 security hotspots that need review.

License

jenkins-library is licensed under the EPL-2.0 License. This license is Weak Copyleft.

Weak Copyleft licenses have some restrictions, but you can use them in commercial projects.

Reuse

jenkins-library releases are not available. You will need to build from source code and install.

Installation instructions, examples and code snippets are available.

It has 188 lines of code, 0 functions and 4 files.

It has low code complexity. Code complexity directly impacts maintainability of the code.

Top functions reviewed by kandi - BETA

kandi's functional review helps you automatically verify the functionalities of the libraries and avoid rework.
Currently covering the most popular Java, JavaScript and Python libraries. See a Sample of jenkins-library

Get all kandi verified functions for this library.

jenkins-library Key Features

No Key Features are available at this moment for jenkins-library.

jenkins-library Examples and Code Snippets

No Code Snippets are available at this moment for jenkins-library.

Community Discussions

Trending Discussions on jenkins-library

SAP Jenkins on Kubernetes

Jenkins neo.sh not found error while using SAP Project Piper Library

Calling a Closure from jenkins-library inside job's pipeline

QUESTION

SAP Jenkins on Kubernetes

Asked 2020-Mar-05 at 08:22

got some questions running project piper on Kubernetes. We did the setup like described in

https://sap.github.io/jenkins-library/guidedtour/

I assumed that a build will run "out-of-the-box"... but it isn't. Invoking a mtaBuild results in a message ... Cannot connect to docker daemon ... permission denied

Not sure if we have to set env variable ON_K8S. If we set it ... the build is waiting forever for a node to come up.

Is there any setup guide for Kubernetes? Do we have to configure a pod Template in the Jenkins configuration and work with container("container_name") in the Jenkinsfile ?

Is the Jenkins agent https://hub.docker.com/r/ppiper/jenkins-agent-k8s already preconfigured? Do we have to set it over env variable?

...

ANSWER

Answered 2020-Mar-05 at 08:22

Updated answer:

The cx-server scripts are not made for running in Kubernetes, they are built for a "plain docker" setup (a linux server/vm with docker installed).

For scaling on Kubernetes, two options are available:

Using the jenkins master image in a pod as described in this blog post, or using it in a "plain docker" setup and optionally having additional agents on kubernetes.

Additional documentation on this topic is here

Source https://stackoverflow.com/questions/60511135

QUESTION

Jenkins neo.sh not found error while using SAP Project Piper Library

Asked 2020-Feb-14 at 14:35

I am setting up a CI/CD pipeline scenario for SCP NEO environment based on the prebuilt pipeline on Project Piper. I tried to execute a pre-built library called Project Piper for Jenkins and I got the following error.The error seems neo.sh is not found. But I downloaded neo SDK and placed it in the neo-sdk folder. Also neo.sh is available inside /opt/sap/neo-sdk/neo-java-web-sdk-3.39.10/tools folder in linux

Please see error in Jenkins

please see .pipeline/config file where that location is referenced

Docker is not used and I set-up Jenkins in ubuntu inside Vmware virtual machine.If the docker is not available,the library is capable of running locally in Jenkins server. I am keeping neo-sdk tool in a local folder which contain neo.sh which is used to deploy application to SAP Cloud Platform.I am not writing any script my own as everything is prebuilt scripts from Project piper

...

ANSWER

Answered 2020-Feb-11 at 21:55

As already state in the GH issue you should extend your PATH env var to also look inside /opt/sap/neo-sdk/neo-java-web-sdk-3.39.10/tools.

You do this by executing export PATH=$PATH:/opt/sap/neo-sdk/neo-java-web-sdk-3.39.10/tools.

Or an even better way would be to symlink the neo.sh into a folder that is already on the PATH.

With echo $PATH you can display the env var and have a look which directories are already exposed.

Source https://stackoverflow.com/questions/60042052

QUESTION

Calling a Closure from jenkins-library inside job's pipeline

Asked 2020-Jan-22 at 09:01

I have jenkins_library with handleCheckout.groovy which handles checkout:

...

ANSWER

Answered 2020-Jan-22 at 09:01

Could you please your setup

1) handleCheckout.groovy must be located in vars folder (has to check) 2) handleCheckout.groovy must have def call (you have to change) 3) Inside your pipeline you have to run Jenkinsfilename(), in your case handleCheckout

Just in case doc - https://jenkins.io/doc/book/pipeline/shared-libraries/

So at the and you have to change procedure name to def call and check Jenkins file location (must be in vars folder inside shared library)

Source https://stackoverflow.com/questions/59854814

Community Discussions, Code Snippets contain sources that include Stack Exchange Network

Vulnerabilities

No vulnerabilities reported

Install jenkins-library

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