This question already has answers here:
"Build Periodically" with a Multi-branch Pipeline in Jenkins
(6 answers)
Closed 6 years ago.
I created a GitHub Organization project on Jenkins. This scans my GitHub profile and sets up a Multibranch Pipeline (if I understood correctly). In the end I have a bunch of projects which are executed by the respective Jenkinsfiles. If I push something to GitHub or open new Pull Requests, Jenkins gets triggered and everything works as expected.
Unfortunately there is no way of configuring these Projects and I have a project which I want to build daily, regardless of changes on GitHub. Is there a way to trigger a single project daily? I am also fine with building every project daily.
Sorry, if I missed some information or said something wrong. Jenkins and its plugins are very hard to understand for me, at the moment. Please ask if something is unclear.
If you look at your Multibrach Pipeline then you will see a button Configure at the left side. If you click on there you get to the configuration of the project.
Note: If you do not see the button it is possible that you do not have sufficient permissions.
Once you are inside the configuration, there is a section called "build triggers" where you can check a checkbox to start the build time based/periodically.
Inside there you will have to add a so called cron expression.
Example:
H 7 * * * to start a build daily at 7AM.
Edit:
If you are not able to edit the configuration of a certain job it might be possible that you create a periodially scheduled Multijob Project that triggers a build on your original job.
Related
I have a declarative pipeline that executes almost regularly.
Upon specific condition (evaluated during the job run) I'd like to keep the job longer than usual.
Usual runs I keep for one week.
If condition 1 is true I want to keep the build for up to a month.
If condition 2 is true, I want to keep the build for up to six months.
Can Jenkins do something like that out of the box, or can it do it by adding some plugin?
So I found a solution to this job: Jenkins out of the box cannot do what I was searching for. However Jenkins can run plugins. Not finding any plugin that would satisfy my need I started creating my own. Here are the highlevel steps if someone wanted to do the same:
follow the Jenkins Plugin development tutorial. From that you have a plugin with a build step and a build action
modify the build action to store the information about the two conditions, or even better the resulting keep period.
modify the build step so the information can be set from freestyle builds or pipeline steps.
create a BuildDiscarder that reads the information from the action and honors it before triggering a delete
We are using the Parameterized Builds plugin and a matrix combination parameter. So now, when we build this job, we select which of the combinations we want to build and one "child job" is created for each one that is selected.
Each of these jobs runs their build steps and post build actions. However, I have also noticed that the post build actions run for the "parent job" as well.
For example, we have the job configured to post a message to Slack upon success. Now, if I build the job with parameters and select one configuration to build, I will get two Slack notifications. One for the main job and one for the selected configuration.
Example Slack output, note one with the config selected and one without:
| My Jenkins Project » My Job » my config - #51 Success after 1 min 54 sec (Open)
| My Jenkins Project » My Job - #51 Success after 1 min 55 sec (Open)
So my question is, how can I prevent post build actions from running on the main job?
EDIT: Since creating this question I found this GitHub issue on the Slack plugin that describes exactly what I'm seeing. So it looks like this functionality should be up to the plugins and that a new version caused a regression in this particular plugin.
Perhaps the question is better suited as: Is it a plugin's responsibility to determine whether it is running in the global job or in a configuration job as part of a multi-configuration project?
Whether a message should be posted on Slack for only the child jobs or the parent job also should be part of the configuration that the plugin provides. Here's an example from your github link. The hipchat plugin gets this right:
A similar option from the Slack plugin would solve your problem, there seems to be a PR here to fix it. You can revert back to an older version (<= 2.0) to solve this meanwhile.
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:
When I create a plain pipeline project I have the option to periodically poll the scm and if changes are detected, the build is run. that worked well for me.
Now I created a multibranch pipeline and added 2 branches. However, in the configuration I can not set the same as in the normal pipeline project, because it tells me I can only view the configurations of the sub-branch-projects.
Maybe I'm also doing it wrong, so I try to tell you what I actually want to achieve.
I have a PHP project inside of a Git repository. There are two branches that I want to be built on new commits (when pushed to the main repository)
The main repository resides on a self hosted version of Bitbucket Server. If possible, I want to avoid hooks and let Jenkins poll for changes on the bitbucket server. So how can I achieve that?
You just need to check the option Periodically if not otherwise run trigger at the multibranch level. This replaces per-job polling, because it also detects new branches and the like.
If I got you right, all you want to do is to build ONLY these 2 branches?
If so, under "Branch Sources" just click the "Advanced" and fill in the textfield "Include branches" your branches e.g. test test2 (note the space between the branch names)
Actually you'll have configure SCM pollig (the way you expect it) in the Jenkinsfile itself. It's the properties DSL elelement that handles the configuration:
properties([
pipelineTriggers([pollSCM('H 20 * * 1-5')])
])
Anyways I highly suggest to have a closer look at the Pipeline Snippet Generator:
<your-jenkins-url>/pipeline-syntax/
it s easy to miss but extremely helpful and it s populated based on your currently installed plugins. There you will also find a comprehensible set of options available for properties