I have my Jenkins job defined to use a timestamp for the build name. I'd also like to be able to use that build name in the code being built. For example, suppose my application prints a "startup" message during initialization. Ideally, I would be able to somehow inject the build name into this startup message.
Example:
Application XYZ, build 20160503-0420, is starting up...
I'm curious what sort of techniques folks have come up with to do something like this.
Thanks!
Well, at first insert build number directly into your code it`s very bad practice.
We create debian package by Jenkins. Debian packages contains control file, some kind of description of package, version, dependency, etc.
In our repo control file contains
Section: misc
Priority: optional
Package: #packagename
Version: 0.1.0+#build~#repo
As you see we keep fixed only major version of software
Then we create package we replace texts started by # with build variables
sed -i 's/#build/$(BUILD_NUMBER)/' $(FAKEROOT)/DEBIAN/control
sed -i 's/#repo/$(REPONAME)/' $(FAKEROOT)/DEBIAN/control
sed -i 's/#packagename/$(PROJECTNAME)/' $(FAKEROOT)/DEBIAN/control
And after that we publish, deploy, send email, doing all Jenkins magic.
I think you can build binary and distribute it
Of course if you want to add this changes into you repository you can use Git publisher, or another source management systems, but tell you again this is bad practice.
We use powershell plugin in Jenkins and this is how we write our job ...
Write-Host Build id $env:BUILD_NUMBER started at Get-Date
For more build parameters refer to below URL
https://wiki.jenkins-ci.org/display/JENKINS/Building+a+software+project#Buildingasoftwareproject-JenkinsSetEnvironmentVariables
Related
I have a local instance of Jenkins. I have previously tried storing the jenkins.yml in my system and giving its path on http://localhost:8080/configuration-as-code. This worked but I want to use a Gitlab repository to store the jenkins.yml file.
I have already tried giving the gitlab link of my jenkins.yml in the path or URL textbox. Some weird things happened, like
1. jenkins broke or huge error console
2. It reapplies the previous configuration(from system path)
jenkins:
systemMessage: "Hello, world"
Your problem as described: you want the job configuration to be saved in GIT and, when a build is triggered, the job should get the current stand of its configuration from there and then, run the build.
Maybe there is a kind of plug-in that does it for you, but I am not aware of any. Maybe anyone?
My suggestion is to define a pipeline job and use a declarative pipeline. It is a file, normally named Jenkinsfile that can be stored in GIT. In the Job, you define the GIT address and when you trigger a build, the file is got from GIT and executed.
There are several flaws in this: pipelines learning curve is not small, you are confronted with groovy (not XML!) and your current XML file is barelly useful.
Maybe someone shows up and tells us about new (for me) plugin that solves your problem using the configuration XML file. In the other hand, pipelines are such a beautyful feature that I encourage you to give it a try
I want to update Jenkins plugin via Artifactory.
Create a remote repo named Jenkins-update
Create a local repo named jenkins-update-center
Get the update-center.json from repo Jenkins-update to local and modify the URL from 'http://updates.jenkins-ci.org/' to my own URL 'https://artifacts.xxx.com/artifactory/Jenkins-update/' in update-center.json, then put update-center.json into local repo.
#!/bin/sh
curl -L -o /tmp/update-center.json http://localhost:8081/artifactory/Jenkins-update-cache/update-center.json
sed -i 's#http://updates.jenkins-ci.org/#https://artifacts.xxx.com/artifactory/Jenkins-update/#g' /tmp/update-center.json
curl -L -uuser:pass -T /tmp/update-center.json "http://localhost:8081/artifactory/jenkins-update-center/update-center.json"
Change the default update site from 'http://updates.jenkins-ci.org/' to 'https://artifacts.xxx.com/artifactory/jenkins-update-center/update-center.json' in Jenkins
There is an error 'SHA-512 digest mismatch: expected=49a22dc23f739a76623d10128b6803f79e0489de3ded0f1d01f3dfba4557136c7f318baaf4749a7713ec4b3f56633f2ac3afc4703e87d423ede029d68f84c74d in 'update site 'default''' when I click 'check now' button.
What should I do to make Jenkins update plugins from Artifactory?
Tkx
As soon as the content of update-center.json changed you need to re-generate "signature" section of this file.
For that you need to generate your key pair (see more details in How to create a local mirror of public Jenkins update site?)
Also you may use the following proposed approach :
there is probably a better way, by having a sandbox Jenkins on a system that has access to the internet. You update the server using the UI and then you can test that updated Jenkins thoroughly. When done, you just need to copy the war and hpi files over to your 'production' Jenkins. now you have even a nice process and QA in place.
Another way is to setup a transparent https proxy between your Jenkins and Artifactory server - in that case update-center.json will not change and signature verification should work fine.
With best regards,
Dmytro Gorbunov
As of 2023-01-10 there is a problem with making a mirror of the jenkins plugins on artifactory.
Artifactory documentation decribes only how to create a mirror: https://jfrog.com/knowledge-base/how-to-configure-artifactory-as-a-mirror-for-jenkins-plugins/
But this is not a complete solution. Because this leads to the situation when every plugin shall be manually updated. Having plugins with bunch of dependencies it is huge effort.
There is a need to generate a file: update-center.json
There is an internal jenkins tool to do this: https://github.com/jenkins-infra/update-center2, but documentation is poor and contains vague statements like:
With a few modifications it could easily be used to generate your corporate update center as well.
Without clear description, what shall be done.
I tried to follow steps and completely failed. Tool require some special environment variables, which are also not documented and so on.
So as of my experience mirroring jenkins plugins on artifactory is practically not possible. And honestly spoken, I would like to be wrong here.
I'm automating the following manual process with Jenkins:
Check out the trunk from svn
Build the code
Run tests
If the tests pass then tag the code and built artefacts
Steps 1-3 are working, but I need some help with tagging in step 4. There are some possible solutions that I've excluded:
The svn-tag plugin which has security issues and not developed
since 2015
The "tag this build" button which is a manual step and doesn't allow
me to select which files are tagged
Using svn command line tools on the slave, because I don't want to rely on them being install (and the same version as Jenkins), also I don't want to expose credentials to the build
Tools seem to be available for Git. Is there another way to do it for svn that I haven't thought of?
What about svn commandline?
Your could try to create a tag using shell :
svn copy http://svn/mywebsite/trunk http://svn/mywebsite/tags/2.2.1 -m "Release 2.2.1 - added new feature"
Source:
http://svnbook.red-bean.com/en/1.6/svn.branchmerge.tags.html
If it works, your step 4 could be a build step called : Execute Shell :
Just put your shell script in the text-area called command. You could use variables for your url, tag number, etc
Finally, you could create a jenkins plugin called svn command line tool to make life easier. Is not complex as many believe.
I wonder if it is possible to remove only one build (including artifacts) from job workspace.
I tried to "Delete Build" in Build History but all it does is remove build reference from Build History table. I know I can ssh to a server and delete files from the command line but I am looking for a way to do it from Jenkins web interface.
After installing Workspace Cleanup Plugin I am able to wipe out current workspace but I want to keep my other builds in the workspace.
In your Jenkins instance, to be able to have folder/per build - set flag "Use custom workspace" in your job's settings. Here is a brief help info from the setting description:
For each job on Jenkins, Jenkins allocates a unique "workspace directory."
This is the directory where the code is checked out and builds happen.
Normally you should let Jenkins allocate and clean up workspace directories,
but in several situations this is problematic, and in such case, this option
lets you specify the workspace location manually.
One such situation is where paths are hard-coded and the code needs to be
built on a specific location. While there's no doubt that such a build is
not ideal, this option allows you to get going in such a situation.
...
And your custom directory path would look like this:
workspace\$JOB_NAME\$BUILD_NUMBER ~> workspace\my-job-name\123
where $JOB_NAME will be "my-job-name" and $BUILD_NUMBER is the build number, eq. "123".
There is one nasty problem with this approach and this is why I wouldn't recommend to use it - Jenkins will not be able to reclaim disk space for outdated builds. You would have to handle cleanup of outdated builds manually and it is a lot of hassle.
Alternative approach, that gives you more control, tools and is able to keep disk space usage under control (without your supervision) is to use default workspace settings and archive your build output (files, original source code, libraries and etc.) as a post-build action. Very-very handy and gives you access to a whole bunch of great tools like, Copy Artifact Plugin or ArtifactDeployer Plugin in other jobs.
Hope that info helps you make a decision that fits your needs best.
I also use "General/Advanced/Use custom workspace" (as in #pabloduo's answer) on a Windows machine with something like:
C:\${JOB_NAME}\${BUILD_NUMBER}
Just wanted to add a solution for getting rid of the build job's workspaces.
I use Groovy Events Listener Plugin for this.
Using the plug-in's standard configuration I just use the following Groovy script:
if (event == Event.JOB_DELETED){
new File(env.WORKSPACE).deleteDir()
}
And now the custom workspace is deleted when the build job is deleted.
Just be aware that this would also delete non-custom workspaces (because the event is triggered for all jobs on your Jenkins server).
I have a task to configure Siebel compile with Jenkins CI tool. I dont know much about siebel. So, please suggest if anyone have ever configure these two before or anyone have some knowledge about integration or tools.
Thanks in advance.
Integrating Siebel build with Jenkins is pretty simple. Steps are as follow,
Add new jnlp slave(window machine) where you have install you toold.
Use repository tool to download object on you window machine. For SVN you can use silk svn or if you are using git them that can be directly integrated with your job as Jenkins provide plugin for same.
Define your folder structure with main folder. like for applet,bc,bo etc.
Call you siebdev.exe to import all object. You can do it by the option /batchimport. It will import all sif file present in directory
siebdev.exe " /c "D:\sea81\Tools_2\BIN\ENU\tools.cfg" /d "Local" /u "USER" /p "PASSWORD!" /batchimport "Siebel Repository" overwrite "d:\workspace_future\objects/Applet"
Once import is complete,start compiling.
tools.cfg" /d "Local" /u "USER" /p "PASSWORD!" /bc "Siebel Repository" "d:\workspace_future\built\siebel.srf"
Now you can also create Browser script, zip it and upload on any ftp system, which can be used to download files during integration.
There is many things which you can play with. For example I create a unique build file which contains repository with latest change, srf file, browser script,and other reference data like lov,system preference etc.
This might help you:
http://siebelunleashed.com/how-to-automate-siebel-full-compile/
It shows how to automate a siebel compilation. Use the first part (command line stuff) and put that in the "Execute Windows Batch Command" section of Jenkins.
I'm not sure how much experience you have with Jenkins, so if you need more details, please post a comment.