New answers tagged jenkins-pipeline
0
There are two approaches to this, neither of them, in my opinion, are especially good as they don't strictly "NOT Fail" the build:
Use a plugin such as Naginator which can be configured to restart the build until it passes. This can be quite frustrating as you need to differentiate between ephemeral/preemptable virtual machines being terminated and a truly ...
0
There is a natural tension here between:
(a) fixing something that is wrong automatically: because for example, a CVE has been created with a high enough severity to need to do something about it.
(b) breaking the system: because the automation introduced a breaking change or a defect.
I have a tendency towards systems being under constant development, ...
1
There are a few different things you can do:
In your CI process, run your new SQL update scripts against a Dockerized SQL Server. This will allow your CI server to reject the changes if there are basic errors in the script.
If you are fully containerized look into tools like Kubernetes. These tools have ways to handle rolling back failed production updates....
0
The Gitlab plugin requires an auth token, you're trying to use an SSH key.
https://github.com/jenkinsci/gitlab-plugin#global-plugin-configuration
"PLEASE NOTE: This auth configuration is only used for accessing the GitLab API for sending build status to GitLab. It is not used for cloning git repos. The credentials for cloning (usually SSH credentials) ...
1
Sometimes it is easier to ask forgiveness than permission.
Instead of trying to figure out whether branch b exists, just try to check it out.
If it fails, checkout branch a.
script {
try {
checkout([
$class: 'GitSCM',
branches: [[name: 'b']],
userRemoteConfigs: [[url: url]]
])
}
...
1
I agree with Omri that you are heading the wrong way. I would recommend using a shared library which implements the pipeline. You would then have a simple Jenkins file which looks all the same. See https://jenkins.io/blog/2017/10/02/pipeline-templates-with-shared-libraries/
Let's say you have a shared library which contains a vars/commonpipeline.groovy ...
0
I believe you are heading in the wrong direction.
The way to implement what you want is to separate the "devops infrastructure logic" (placed in the 'ci-repo') from the pipeline trigger - a jenkinsfile inside the dev-repo, which includes the "devops infrastructure logic" as a tagged artifact.
Pros:
You have a central place to develop (and test) devops code
...
Top 50 recent answers are included
