I need help with Jenkins.
I want trigger over an button in the already successful builded 'build' page (where the testresults, artefacts etc. are listed) one target in an ant script.
Is that possible over an plugin or do I have there to do more?
This is the closest I can see you can get at the moment.
A combination of the Jenkins Batch Task Plugin:
This plugin adds batch tasks that are not regularly executed to
projects, such as releases, integration, archiving, etc. In this way,
anyone in the project team can execute them in a way that leaves a
record.
and Sidebar-Link Plugin:
This simple plugin adds an Additional Sidebar Links section in the
main Jenkins configuration page, with settings for link URLs, texts
and icons. These links will be shown in the top-level Jenkins pages
(main page, user list, build history, My Projects and other project
view tabs). Sidebar links for particular jobs may also be added in the
job configuration pages.
You can use the Sidebar-Link Plugin to add these to the project page, but it doesn't appear to support adding it to the build page as of yet - might be worth raising a JIRA ticket and requesting this as it was part of the original ticket.
In the Batch Task Plugin you can define a task - that might well be an Ant invocation - this example is called 'release'.
Then you can run the task from the web interface:
And records of these post-build tasks are kept and accessible:
Related
Given the following situation
main-job builds and tests a project
installer-job copies artifacts from main-job, and packages them into an installer
installer-job is set as downstream project of main-job via Parameterized Trigger Plugin.
But the installer-job should only be triggered on-demand from main-job's build page.
It's possible to trigger the downstream job on the project page:
But it doesn't seem possible to trigger the build from a specific build page.
Is there any option to get such a trigger button on the build page?
Note: It's a freestyle project, not a pipeline one. So things like the Build Pipeline plugin don't help, unfortunately.
An elegant solution is possible via the Promoted Builds Plugin. "Promotion" is some activity that's performed when a build fulfills certain criteria, like
build was successful
all downstream builds passed
explicit, interactive confirmation
In your case, this condition will be simple: just "main-job" needs be successful, and you will want to confirm explicitly.
There's lots of possible steps that can be triggered as promotion activity -- what you want is to trigger a build of the "installer-job", which can be configured easily.
To summarize, for "main-job", you will configure something like this:
When you do that, the 'main-job" builds will feature a "Promotion Status" button. After pressing the "Approve" button there, the promotion will be enabled and the "install-job" will start building:
After creating a Multibranch Pipeline in Jenkins I can easily tell it to poll for changes or additions of any branches and it will automatically create jobs for and build those branches. I told the Multibranch job to also discover tags, so it automatically creates jobs for each tag, which is great.
Is there a clean way for Jenkins to automatically build those tags as well, instead of me having to trigger them manually? As you can see below, the job for the tag is there, but I have to manually build it.
I would have commented with this, but I don't have enough reputation. I believe this is a duplicate of Jenkins Multi-branch pipeline doesn't schedule tag jobs. See my answer there, copied below.
In short, if you build and install the Jenkins plugin available at https://github.com/AngryBytes/jenkins-build-everything-strategy-plugin then you can add a Build Everything strategy which will automatically build tags.
Not automatically triggering a build for discovered tags seems to be by design according to JENKINS-47496. Stephen Connolly offers an explanation and suggestion for what you might do:
Stephen Connolly added a comment - 6 days ago
Tags are not built by default (because otherwise you could have a
build storm when checking out a repository) and worse, the order tags
will be built in is unpredictable... and you might have a Jenkinsfile
that deploys to production when a tag is built.
There is an extension point in branch-api called BranchBuildStrategy
which - if implemented - will allow deciding whether to build tags.
See
https://github.com/jenkinsci/github-branch-source-plugin/pull/158#issuecomment-332773194
for starting point on how to create such an extension plugin... I
believe there is some work on one at
https://github.com/AngryBytes/jenkins-build-everything-strategy-plugin
As #tommy-ludwig says, you need an additional plugin providing a Build Strategy ; since his original post, Stephen Connolly has published the Basic Branch Build Strategies Plugin which among others provides a strategy to build tags.
If, like me, you don't care if the tags show up on a separate tab, you just want the tags to be visible when your various branches are being built (which implies that your tags will be built), then do this:
In your multibranch pipeline's configuration, go to "Branch Sources", "Git", "Behaviors", and add "Advanced clone behaviors". By default, when you add this you will see that "Fetch tags" is checked. Voila!
We are now experimenting with multi-branch Pipeline builds. The main advantage of the feature is that it allows us to automatically create new Jenkins jobs whenever a new branch is created.
However, it also is a bit more difficult to implement than the old way of selecting how to do the build using the UI. Plus, certain features seem to be missing.
For example, in Jenkins Freestyle jobs, we are able to use the Jenkins UI to browse through the workspace, download individual files, and even wipe out the workspace. We found this helpful when builds went awry or if the developer needed a particular built asset that wasn't archived.
I've noticed in the Jenkins Pipeline jobs the UI no longer offers access to the workspace. I know I can archive the workspace, but I really don't want to save it -- especially for each and every build. I simply want to be able to browse the workspace or clean it out if something is causing problems with the build process.
Is there a way to get back this feature via the pipeline? I don't want to archive the workspace for each build (space issues), but I do want to be able to see what the workspace looks like if there are problems.
Freestyle Job with Workspace UI
Pipeline Job. No ability to browse Workspace
You can see your work space in three simple steps:
First, go to the build run you are interested in and click “pipeline steps”.
Then click “allocate node: start”. If you have multiple nodes, you’ll need to do this more than once.
Then you click the workspace link. (it appears on the left pane).
You can also click on Build Artifacts on build page:
I have a fairly complicated Jenkins job that builds, unit tests and packages a web application. Depending on the situation, I would like to do different things once this job completes. I have not found a re-usable/maintainable way to do this. Is that really the case or am I missing something?
The options I would like to have once my complicated job completes:
Do nothing
Start my low-risk-change build pipeline:
copies my WAR file to my artifact repository
deploys to production
Start my high-risk-change build pipeline:
copies my WAR file to my artifact repository
deploys to test
run acceptance tests
deploy to production
I have not found an easy way to do this. The simplest, but not very maintainable approach would be to make three separate jobs, each of which kicks off a downstream build. This approach scares me for a few reasons including the fact that changes would have to be made in three places instead of one. In addition, many of the downstream jobs are also nearly identical. The only difference is which downstream jobs they call. The proliferation of jobs seems like it would lead to an un-maintainable mess.
I have looked at using several approaches to keep this as one job, but none have worked so far:
Make the job a multi-configuration project (https://wiki.jenkins-ci.org/display/JENKINS/Building+a+matrix+project). This provides a way to inject the job with a parameter. I have not found a way to make the "build other projects" step respond to a parameter.
Use the Parameterized-Trigger plugin (https://wiki.jenkins-ci.org/display/JENKINS/Parameterized+Trigger+Plugin). This plugin lets you trigger downstream-jobs based on certain triggers. The triggers appear to be too restrictive though. They're all based on the state of the build, not arbitrary variables. I don't see any option provided here that would work for my use case.
Use the Flexible Publish plugin (https://wiki.jenkins-ci.org/display/JENKINS/Flexible+Publish+Plugin). This plugin has the opposite problem as the parameterized-trigger plugin. It has many useful conditions it can check, but it doesn't look like it can start building another project. Its actions are limited to publishing type activities.
Use Flexible Publish + Any Build Step plugin (https://wiki.jenkins-ci.org/display/JENKINS/Any+Build+Step+Plugin). The Any Build Step plugin allows making any build action available to the Flexible Publish plugin. While more actions were made available once this plugin was activated, those actions didn't include "build other projects."
Is there really not an easy way to do this? I'm surprised that I haven't found it and even more surprised that I haven't really seen any one else trying to do this? Am I doing something unusual? Is there something obvious that I am missing?
If I understood it correct you should be able to do this by following these Steps:
First Build Step:
Does the regular work. In your case: building, unit testing and packaging of the web application
Depending on the result let it create a file with a specific name.
This means if you want the low-risk-change to run afterwards create a file low-risk.prop
Second Build Step:
Create a Trigger/call builds on other projects Step from the Parameterized-Trigger
plugin.
Entery the name of your low-risk job into the Projects to build field
Click on: Add Parameter
Choose: Parameters from properties File
Enter low-risk.prop into the Use properties from file Field
Enable Don't trigger if any files are missing
Third Build Step:
Check if a low-risk.prop file exists
Delete the File
Do the same for the high-risk job
Now you should have the following Setup:
if a file called low-risk.prop occurs during the first Build Step the low-risk job will be started
if a file called high-risk.prop occurs during the first Build Step the high-risk job will be started
if there's no .prop File nothing happens
And that's what you wanted to achieve. Isn't it?
Have you looked at the Conditional Build Plugin? (https://wiki.jenkins.io/display/JENKINS/Conditional+BuildStep+Plugin)
I think it can do what you're looking for.
If you want a conditional post-build step, there is a plugin for that:
https://wiki.jenkins-ci.org/display/JENKINS/Post+build+task
It will search the console log for a RegEx you specify, and if found, will execute a custom script. You can configure fairly complex criteria, and you can configure multiple sets of criteria each executing different post build tasks.
It doesn't provide you with the usual "build step" actions, so you've got to write your own script there. You can trigger execution of the same job with different parameters, or another job with some parameters, in standard ways that jenkins supports (for example using curl)
Yet another alternative is Jenkins text finder plugin:
https://wiki.jenkins-ci.org/display/JENKINS/Text-finder+Plugin
This is a post-build step that allows to forcefully mark a build as "unstable" if a RegEx is found in console text (or even some file in workspace). So, in your build steps, depending on your conditions, echo a unique line into console log, and then do a RegEx for that line. You can then use "Trigger parameterized buids" and set the condition as "unstable". This has an added benefit of visually marking the build different (with a yellow ball), however you only have 1 conditional option with this method, and from your OP, looks like you need 2.
Try a combination of these 2 methods:
Do you use Ant for your builds?
If so, it's possible to do conditional building in ant by having a set of environment variables your build scripts can use to conditionally build. In Jenkins, your build will then be building all of the projects, but your actual build will decide whether it builds or just short-circuits.
I think the way to do it is to add an intermediate job that you put in the post-build step and pass to it all the parameters your downstream jobs could possibly need, and then within that job place conditional builds for the real downstream jobs.
The simplest approach I found is to trigger other jobs remotely, so that you can use Conditional Build Plugin or any other plugins to build other jobs conditionally.
Our C# solution has a couple of folders that are populated via post-build events (i.e. they are initially empty).
The solution builds fine locally, however when using the TFS build agent, the folders don't show up in the published websites folder.
Any suggestions on how to force TFS to copy the folders over?
This is addressed here: publish empty directories to a web application in VS2010 web project
TFS does not execute the AfterBuild target of your proj file. I believe it will execute the AfterCompile target but this still might not do what you want.
I have used the approach of including dummy files which is simple enough even though its lame.
I've tried the approach of including a powershell script to do some post-publish tasks which works.
More recently I have adopted a convention of including a supplemental MSBuild file that ends in ".package.proj" and added an additional MSBuild execution activity to my Team Build Template that looks for it after the files are dropped to the drop location and then executes it. This provides a simple hook into the Team Build workflow without getting you deep into changing the workflow for a particular build. It's just a single additional activity wrapped in a conditional that looks for the file. If found, execute it.
You could also make a custom build template and use the Workflow activities to perform various cleanup tasks, but it's probably overkill and will increase maintenance on the build templates. Better to keep the customization simple if you can and have it function in a way that doesn't require "opt-out" configuration on builds that don't require the customization. Existing vanilla builds should continue to work as expected after the customization to the template.