We currently have a CircleCI pipeline, that get's triggered whenever a commit gets merged to the test environment.
It builds the app and then runs some tests againsts it using the url of the web app. All this is defined in the config.yml file.
e.g.
Step 1 - Builds the app
Step 2 - Runs tests against the app (on https://)
How can one create a nightly build that only runs tests i.e. Step 2?
In this case, it is not triggered by a commit to the test environment, but is just a scheduled build that runs tests at a specified time
CircleCI supports scheduling jobs through the Scheduled Pipelines feature. From the docs
Scheduled pipelines allow you to trigger pipelines periodically based on a schedule.
You can configure scheduling by choosing your project and then going to Project Settings -> Triggers -> Add Triggers.
In the trigger configuration, add a pipeline parameter, run-tests for instance, which will be passed to the pipeline when the trigger executes the schedule.
Additionally, add the same pipeline parameter to your config.yaml and a when statement to the workflow you want to run, which will check if the pipeline parameter run-tests is present. That should be all the configuration needed to execute a pipeline on a schedule with a specific workflow.
Documentation: https://circleci.com/docs/scheduled-pipelines/
Related
All my Jenkins jobs are triggered both by a Github webhook, but also via a scheduled build one per week. The build process is heavily cached to make the webhook CI builds finish quickly.
I would like to add a line to my build script which wipes the cache during the weekly scheduled build, and make it build from scratch. Is there a variable in the build script to identify if a build was triggered by a webhook or schedule?
Maybe the envInject plugin will give you what you need?
This plugin also exposes the cause of the current build as an
environment variable. A build can be triggered by multiple causes at
the same time e.g. an SCM Change could have occurred at the same time
as a user triggers the build manually.
The build cause is exposed as a comma separated list:
BUILD_CAUSE=USERIDCAUSE, SCMTRIGGER, UPSTREAMTRIGGER, MANUALTRIGGER
In addition, each cause is exposed as a single envvariable too:
BUILD_CAUSE_USERIDCAUSE=true
BUILD_CAUSE_SCMTRIGGER=true
BUILD_CAUSE_UPSTREAMTRIGGER=true
BUILD_CAUSE_MANUALTRIGGER=true
Jenkins any version.
I have two versions: 1.642.3 or 2.32.3
I have a Jenkins job jobA. Let's assume this job deploys an artifact to a target deploy server.
It takes 2 parameters, artifact name and target deploy server.
Execute concurrent build is currently DISABLED i.e. not check marked.
Assuming I launched multiple builds on this job manually -or via Jenkins CLI -or via Rest API way (i.e. via some automation/integration/parent upstream job calling this job).
I now see, there is one Jenkins build in-progress -and- all other N
no. of runs are in "queued" mode.
Let's assume I have close to 100+ such builds in the queue (ready to be launched as soon as the in-progress one completes), I'm trying to see if there's a way I can PAUSE the existing queued builds (PS: I do NOT want to cancel them) and launch a new build (which I want to deploy urgently) and once that's done, UNPAUSE the queued builds (so that I don't have to cancel all of them and re-submitting/re-building them again by remembering what were the parameters passed -- for artifact name and target deploy server).
My 3 Conditions:
1) One of my current situation is the server where this job is running is one Jenkins master/slave machine (which have some credentials that can't be taken to other machines i.e. I can't replicate the source Jenkins machine (where the job is running as a slave(s) and thus, I can't use bunch of slaves) and
2) This job also creates some runtime folders/files at a common location on the source machine which I don't want to get overwritten by running concurrent / parallel builds if I enable "Execute concurrent builds". I know, the workspace for concurrent builds is individual to each job run, but not if the job is creating a common folder/file during it's run.
3) I don't want to create a copy of this job :)
In one sentence, is it possible to PAUSE existing queued builds (or some of the queued builds) so that I can launch a new build or make other ones take priority as the next build and then UNPAUSE the paused ones to resume (as launched without requiring them to relaunch)?
You can use Priority Sorter Plugin for this.
Add a new string parameter to the job, for example BUILD_PRIORITY and set default value to 2. Then in Job Priorities menu select Use Priority from Build Parameter priority strategy and put that parameter there.
Now you can run 100+ jobs with the default BUILD_PRIORITY parameter value (2) and if you need to launch a new build urgently just set that parameter to 1 and it will be the first build in the queue.
From Jenkins plugin (ie. Delivery Pipeline, Parameterized Trigger), we could setup a pipeline which contains multiple jobs in sequence, for instance: Build -> Unit Test -> Deploy To DEV.
Now, for each pipeline, we want to stop after "Unit Test" because we need to wait for someone to approve the deployment before it can go on (We use JIRA as the tracking system for this).
Say when, someone approves the deployment ticket in JIRA, we already setup a post action to fire and trigger a job in Jenkins, say "Deploy To Dev" in this case. However, this job will run independently outside the pipeline.
Is there a way, we can trigger the down stream job from script within an instance of a pipeline so it can carry over all the parameters from upstream and shown as part of the pipeline?
Thx
We have set up a Jenkins instance as a remote testing resource for our developers. Every time a tag is created matching our refspec a job is triggered and the results emailed to the developer.
A job is defined as follows:
1 phase consisting of three jobs (frontend tests, integration tests,
unit tests)
All subjobs are executed, irrespective of success
Email the developer the test results
This setup mostly works except for two issues:
I cannot get the job to run in parallel. The subjobs run in
parallel, but only one instance of the job runs at a time. Is this
something I can configure differently somewhere, or is this inherent
in the way the plugin works?
The main job checks out and occupies one of our build servers for
the duration of the job. Is there a way to do git polling and then
just grab the hashref and release the build server on which the
polling was done before continuing building the subjobs?
In the multi job plugin, everything runs in parallel that is listed in the same "Phase", however the multijob itself needs somewhere to run. If you have a build followed by a test phase, you can add a "Build Phase" prior to the test phase, and only that phase will require a "build server".
There is an option called "Execute concurrent builds if necessary" that will allow multiple jobs of the same name to run simultaneously. This option must be set for the parent job and the subjobs as the default behavior of Jenkins is to only allow one build of a Project (job) to run at a time. Beware: Read the comments as this may have unintended side effects.
Not clear what you mean about polling however if using git, you may want to use webhooks so that pushes to the git repository directly invoke Jenkins. No need to poll.
I'm using the Jenkins DSL plugin to automatically create build jobs for all branches of a git project. The DSL plugin is triggered by web hooks so that it is run immediately after a new branch was created. The generated build jobs for each branch are also configured to be triggered by web hooks.
The problem with the current setup is, that the build will only be executed after the second commit. The first commit will trigger the Jenkins DSL plugin to create the respective Jenkins Job and the second commit will then trigger the newly created job.
Is there any way, to start a Jenkins job immediately after it has been created by the DSL plugin? The only thing I can currently come up with is to add an additional build scheduling but I'd rather like to use web hooks only to prevent unnecessary polling.
You can use queue DSL command to schedule a build, see https://github.com/jenkinsci/job-dsl-plugin/wiki/Job-DSL-Commands#queue.
To queue the job only if it's new, you need to use the Jenkins API to test if the job already exists.
if (!jenkins.model.Jenkins.instance.getItemByFullName('my-job')) {
queue('my-job')
}