We are attempting to reference a shared library in Jenkins in a pipeline using the syntax described here with #branch_name syntax. We have the "Allow Default Version to be overwridden" setting set. Yet, the pipeline ignores changes in the branch, and uses the version of the library in master. Any advice on additional settings/configuration needed or suggestions to make this work are appreciated.
We tried this syntax specifically: #Library('library_name#feature_branch_name')
Additionally, I specifically see an entry in the console output: "Loading library library_name#feature_branch_name". Yet, somehow it ignores the changes that have been commit in that branch, instead running against master.
Related
I'm trying to set up a build using Multibranch. I'm basically having the same problem as stated here, but our SCM is Subversion. The Bug in the Bitbucket Branch Source Plugin as described here can therefore be ruled out, especially since our Jenkins has the newest version installed anyway.
I tried to find a similar ticket regarding my problem, but couldn't find one, so here I am.
As this particular project is configured in a way that configuration files (including something like the Jenkinsfile) are to be stored in a subfolder, I don't know what else to try, apart from configuring individual jobs. I'd rather stick to using Multipipelines, however, as they help keeping the build jobs tidy.
I want to understand the difference between external and internal library in Jenkins pipeline.
I read the Extending with Shared Libraries. It says about the libraryResource step such:
A resources directory allows the libraryResource step to be used from an external library to load associated non-Groovy files. Currently this feature is not supported for internal libraries.
What do the external and internal mean? I guess that:
Internal library is gotten from a repository which is the same with a Jenkinsfile
External library is gotten from a repository which is not the same with a Jenkinsfile
Is my understanding right?
Thanks.
That line in documentation has been added a 2016, and in the same commit there is a reference to "internal" libraries being "legacy".
I have worked some time with Jenkins Pipeline now, and until now never heard of "internal" Pipelines -- I think for Pipeline Libraries as they are defined in 2022 are always "external".
Edit: Only some month before the line was added to documentation, a [JENKINS-31155] Shared libraries PR was merged to the plugin implementing Shared Libraries.
If you check the readme at that time, it tells:
Defining the internal library
An older mode of sharing code is to deploy sources to Jenkins itself. [...]
Thus:
External Library: Pushed to a SCM outside Jenkins.
Internal library: Pushed to a Git Repo within Jenkins. (Legacy, not supported anymore)
I'm using the plugin from Jenkins for the integration with Phabricator. Everything works perfectly during the integration, but when an arc diff is executed, the only files received on the Jenkins job is the files edited or created by the arc diff. This is a problem when creating microservices and editing files that could potentially affect to other microservices.
Any thoughts on how to get the whole workspace from the repository (hosted also in Phabricator) to be tested, instead of only the diff files?
I've created an issue on the plugin, here is the link:
https://github.com/uber/phabricator-jenkins-plugin/issues/334
Using git plugin and the repository URL, has been quite straightforward: added the URL of the staging area (in my case is the same as the repository) and git credentials (as username/password). The only trick is to indicate which tag we need to test. Since phabricator staging areas uses two tags per diff (phabricator/base/${DIFF_ID} with the base code of the diff and phabricator/diff/${DIFF_ID} with the whole code with the diff applied), i used the following setting:
As result, git plugin will build the code of the whole project with the diff applied.
More information about the integration and the needed variables can be found here:
https://github.com/uber/phabricator-jenkins-plugin
Last time I've upgraded Stash Pullrequest Builder Plugin to version 1.9 and after that any triggered build has empty parameter list (parameter variables like ${pullRequestId} specified in documentation are not available: https://github.com/jenkinsci/stash-pullrequest-builder-plugin/blob/master/README.md). Now I've tried version 1.10 and have the same issue. With version 1.8 everything is working fine.
1.8:
1.9 / 1.10:
I am using Jenkins in version 2.180 and Git Plugin in version 3.10.0
Maybe some of you experienced the same issue? I would be appreciated for any help.
Jenkins was changed in version 2.3 to disallow adding parameters to a build if they are not declared in the project configuration. The motivation was to prevent a security issue when a project controlled by an attacker invokes another project with arbitrary parameters. Since the parameters are seen as environment variables by the build scripts, the attacker could make the build load an untrusted library. Since its possible for different projects to be controlled by different users and run with different privileges, such behavior would allow the attacker to exploit permissions of a project he or she is not allowed to configure. The issue is known as SECURITY-170.
Stash Pull Request Builder was adding 10 parameters to the build to provide information about the pull request being built. Following the SECURITY-170 implementation, the plugin was changed in version 1.7.0 to pass those values as environment variables as well. Those environment variables are recorded to the build history. They can be viewed if Build Environment Plugin is installed.
Starting with version 1.9, Stash Pull Request Builder plugin removed the old mechanism of passing pull request data through parameters, as it was causing a large number of warnings in the Jenkins log.
The plugin's README.md file has just been updated to use the term "environment variables" to avoid confusion.
If you really need parameters, you can define them for the project. Starting with the next version of the plugin (presumably 1.11), the configured parameters will be populated with the same values that are available through the environment variables.
Jenkins (on a Kubernetes node) is complaining it requires a newer version of Jenkins to run some of my plug-ins.
SEVERE: Failed Loading plugin Matrix Authorization Strategy Plugin
v2.4.2 (matrix-auth) java.io.IOException: Matrix Authorization
Strategy Plugin v2.4.2 failed to load.
- You must update Jenkins from v2.121.2 to v2.138.3 or later to run this plugin.
The same log file also complains farther down that it can't read my config file... I'm hoping this is just because of the version issue above, but I'm including it here in case it is a sign of deeper issues:
SEVERE: Failed Loading global config
java.io.IOException: Unable to read /var/jenkins_home/config.xml
I'd either like to disable the plug-ins that are causing the issue so I can see the Jenkins UI and manage the plug-ins from there, or I'd like to update Jenkins in a way that DOES NOT DELETE MY USER DATA AND JOB CONFIG DATA.
So far, I tried disabling ALL the plug-ins by adding .disabled files to the Jenkins plug-ins folder. That got rid of most of the errors, but it still complained about the plug-in above. So I removed the .disabled file for that, and now it's complaining about Jenkins not being a new enough version again (the error above).
Note: this installation of Jenkins is using a persistent storage volume, mounted with EFS. So that will probably help alleviate some of the restrictions around upgrading Jenkins, if that's what we need to do.
Finally, whatever we do with the plug-ins and Jenkins version, I need to make sure the change is going to persist if Kubernetes re-starts the node in the future. Unfortunately, I am pretty unfamiliar with Kubernetes, and I haven't discovered yet where these changes need to be made. I'm guessing the file that controls the Kubernetes deployment configuration?
This project is using Helm, in case that matters. But again, I hardly know anything about Helm, so I don't know what files you might need to see to make this question solvable. Please comment so I know what to include here to help provide the needed information.
We faced the same problem with our cluster, and we have a basic explanation about that, but not sure about it (The following fix works)
That error come with the fact that you have installed Jenkins via Helm, and their plugins through the Jenkins UI. It works if you decide to never reboot the pod, but if one day, jenkins have to make his initialization again, you will face that error.
Jenkins try to load plugins from the JENKINS_PLUGINS_DIR, which is empty, so the pod die.
To fix the current error, you should specify your plugin in the master.installPLugins parameter.
If you followed a normal install, just go on your cluster and
helm get values jenkins_release_name
So you may have something like that:
master:
enableRawHtmlMarkupFormatter: true
installPlugins:
- kubernetes:1.16.0
- workflow-job:2.32
By default, some values are "embedded" by helm to be sure that jenkins works, see here for more details: Github Helm Charts Jenkins
So, just copy it in a file with the same syntax and add your plugins with their versions. After, you have just to use the helm upgrade command with your file on your release:
helm upgrade [RELEASE] [CHART] -f your_file.yaml
Good luck !