New answers tagged jenkins-pipeline
0
I found exactly what I was looking for-
[Jenkins plugin] (https://wiki.jenkins.io/display/JENKINS/Lockable+Resources+Plugin)
Which let you create a lock between, slaves , different jobs and more..
(in contrast to the plugin description)
0
Some credential types cannot be bound directly in an environment section. From the docs :
If you need to set credentials in a Pipeline for anything other than secret text, usernames and passwords, or secret files - i.e SSH keys or certificates, then use Jenkins' Snippet Generator feature, which you can access through Jenkins' classic UI.
So the ...
0
The variable must be defined in a script section.
pipeline {
agent none
stages {
stage("first") {
script {
foo = "bar"
}
sh "echo ${foo}"
}
}
}
0
There is no perfect way to do this that I know of. To explain why, take this pipeline script as an example:
node('my-first-node') {
stage('my-first-stage') {
// some steps here
}
}
node('my-second-node') {
stage('my-second-stage') {
// some steps here
}
}
node('my-first-node') {
stage('my-third-stage') { // must be run after my-second-...
0
apparently docker needs to be installed on jenkins master in order for jenkins to be able to launch the docker on the server.
After installation of docker (even without the docker daemon running on jenkins master); jenkins was able to launch the docker on my-server.
0
While I don't know Bitbucket-specific solution, when it comes to triggering Jenkins builds, I prefer using a simple post-receive Git hook.
In Jenkins select Trigger this build remotely (or something similar, it's usually the very first option in Build triggers section), then set up the post-recevie hook to something like:
#!/bin/bash
username=user
token=...
0
I recommend using the Bitbucket Branch Source Plugin which gives much better control over push build triggers than the default Pipeline job type.
The problem with your current setup is that the "branch to build" setting only configures the branch of the repository that Jenkins checks out, not necessarily which branches will trigger a build.
0
I figured it out. I was cloning directly into the workspace and then setting my environment variables to point to the workspace as well. I modified both those things. I now create a dir in my workspace and clone into it and I also set my environment variables to directories inside my workspace. Like so:
node('build-01') {
withEnv(["CMAKE_INSTALL_DIR=${...
0
I usually set the credential NAME into an environment variable
environment {
CERT = 'mycert'
}
Then I can use that name where ever I need it
withCredentials([usernamePassword(credentialsId: "${env.CERT}",
passwordVariable: 'CERT_PASSWORD',
usernameVariable: 'CERT_USER')]) {
// Do ...
0
There is a good practice called multistage build, in which you have one Dockerfile containing various image definitions that depend from one another, this helps you keep all your images updated with the latest changes and copy artifacts from one to another; this also helps reducing the image size if done right.
A simple example is like the following:
FROM ...
1
Both are excellent tools, but it depends on your use cases for which is better. I would highly recommend using the entire AWS Ci/Cd suite (CodeBuild/CodePipeline/CodeDeploy) to gain the full benefit of using your resources in AWS. Here are pros for both:
Jenkins
Multitude of customizability plugins
Integration with all cloud providers (GCP, Azure, etc.)
...
0
You have not instantiated the Utils class in the myorg classpath so you cannot reference the method echoTest(). Try Utils.echoTest or just echoTest()
0
When you see scriptsecurity.sandbox error, that means you need to allow the script from Jenkins script approval page https:///scriptApproval/
Also I would recommend you not to import your package directly within your pipeline. Instead I would define a step under ./vars folder and only there import the custom package
Top 50 recent answers are included
