The following code is an "Execute Shell" build step in Jenkins. The job pulls from a repo which contains a file ranger-policies/policies.json. What I'd like to do is update that file (with a curl command, in this case) and then commit the change to source control and update the remote repo. The job successfully pulls from the remote repo in the "Source Code Management" section of the job configuration page over SSH using SSH keys. However, when the job gets to the "git push origin master" line in the "Execute Shell" step, I get a Permission denied (publickey) error, as if those same SSH keys which allowed me to successfully pull the repo are not available in the "Execute Shell" step when I want to push.
curl -X GET --header "text/json" -H "Content-Type: text/json" -u user:pass "http://my-url.com/exportJson" > ranger-policies/policies.json
git add ranger-policies/policies.json
git commit -m "udpate policies.json with latest ranger policies `echo "$(date +'%Y-%m-%d')"`"
git push origin master
I ended up figuring out how to make it work. The solution involves using the SSH Agent plugin. Here's a step-by-step that describes how I did it, hopefully it helps someone else:
First, create a new pipeline job.
Then, as hinted at in this post from Jenkins' documentation, go to the home screen for your new pipeline job, and click on "Pipeline Syntax." Choose "git: Git" as the "Sample Step, and enter the git repo you want to push to in the "Repository URL" field. Then choose the corresponding valid SSH keys for that repo from the "Credentials dropdown." Everything should look like this:
Grab the value of "credentialsId", highlighted with red in the above screenshot. You'll need it later.
Install the "Workspace Cleanup Plugin" (https://wiki.jenkins.io/display/JENKINS/Workspace+Cleanup+Plugin, optional) and the "SSH Agent Plugin" (https://jenkins.io/doc/pipeline/steps/ssh-agent/, not optional, required for this process to work).
Now go back to your new pipeline job and hit "Configure," which will take you to the screen where you define the job. Drop the following code into the "Pipeline" section ("Definition" should be set to "Pipeline script"): https://gist.github.com/ScottNeaves/5cdce294296437043b24f0f3f0a8f1d8
Drop your "credentialsId" into the appropriate places in the above Jenkinsfile, and fix up the repo names to target the repo you want, and you should be good to go.
Relevant documentation:
https://jenkins.io/doc/pipeline/examples/#push-git-repo
https://gist.github.com/blaisep/eb8aa720b06eff4f095e4b64326961b5#file-jenkins-pipeline-git-cred-md
https://issues.jenkins-ci.org/browse/JENKINS-28335?focusedCommentId=269000&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-269000
As per this gist, you need to set the remote origin url as per:
git remote set-url origin git#github.com:username/your-repository.git
Related
I setup a simple Jenkinsfile that just echo a few steps.
I setup a new repo on Bitbucket (git) and two branches called master and develop.
When I commit something to master then both branches checkout and build in jenkins. Same behaviour on the develop branch.
Is it possible to limit only master to build in Jenkins once there is a commit to master branch? Similar behaviour to develop?
I think you can use a temporary text file to save last successful build SHA ($LAST_SUCCESSFUL_BUILD_SHA) of each branch. Then, when having a new commit from the repo, we'll check which branch the commit comes from.
CURRENT_SHA=$(git rev-parse HEAD)
if [ $FORCE_REBUILD = true ] || [ $CURRENT_SHA != $LAST_SUCCESSFUL_BUILD_SHA ]; then
echo "New commits available OR it was forced to build."
else
echo "Already up-to-date. Skip build."
curl -v -X POST --data "description=no changes, skip." ${JENKINS_BUILD_URL}submitDescription --user <username>:<password>
curl -v -X POST ${BUILD_URL}stop --user <username>:<password>
echo "Waiting for abort to take effect :D"
fi
If the new commit comes from another branch, it's good to use Jenkins open API to skip the build.
I have applied this for my freestyle jobs but haven't tried with Jenkinsfile.
When writing jenkins pipelines it seems to be very inconvenient to commit each new change in order to see if it works.
Is there a way to execute these locally without committing the code?
You cannot execute a Pipeline script locally, since its whole purpose is to script Jenkins. (Which is one reason why it is best to keep your Jenkinsfile short and limited to code which actually deals with Jenkins features; your actual build logic should be handled with external processes or build tools which you invoke via a one-line sh or bat step.)
If you want to test a change to Jenkinsfile live but without committing it, use the Replay feature added in 1.14.
JENKINS-33925 tracks the feature request for an automated test framework.
I have a solution that works well for me. It consists of a local jenkins running in docker and a git web hook to trigger the pipeline in the local jenkins on every commit. You no longer need to push to your github or bitbucket repository to test the pipeline.
This has only been tested in a linux environment.
It is fairly simple to make this work although this instruction is a tad long. Most steps are there.
This is what you need
Docker installed and working. This is not part of this instruction.
A Jenkins running in docker locally. Explained how below.
The proper rights (ssh access key) for your local Jenkins docker user to pull from your local git repo. Explained how below.
A Jenkins pipeline project that pulls from your local git repository. Explained below.
A git user in your local Jenkins with minimal rights. Explained below.
A git project with a post-commit web hook that triggers the pipeline project. Explained below.
This is how you do it
Jenkins Docker
Create a file called Dockerfile in place of your choosing. I'm placing it in /opt/docker/jenkins/Dockerfile fill it with this:
FROM jenkins/jenkins:lts
USER root
RUN apt-get -y update && apt-get -y upgrade
# Your needed installations goes here
USER jenkins
Build the local_jenkins image
This you will need to do only once or after you have added something to the Dockerfile.
$ docker build -t local_jenkins /opt/docker/jenkins/
Start and restart local_jenkins
From time to time you want to start and restart jenkins easily. E.g. after a reboot of your machine. For this I made an alias that I put in .bash_aliases in my home folder.
$ echo "alias localjenkinsrestart='docker stop jenkins;docker rm jenkins;docker run --name jenkins -i -d -p 8787:8080 -p 50000:50000 -v /opt/docker/jenkins/jenkins_home:/var/jenkins_home:rw local_jenkins'" >> ~/.bash_aliases
$ source .bash_aliases # To make it work
Make sure the /opt/docker/jenkins/jenkins_home folder exists and that you have user read and write rights to it.
To start or restart your jenkins just type:
$ localjenkinsrestart
Everything you do in your local jenkins will be stored in the folder /opt/docker/jenkins/jenkins_home and preserved between restarts.
Create a ssh access key in your docker jenkins
This is a very important part for this to work. First we start the docker container and create a bash shell to it:
$ localjenkinsrestart
$ docker exec -it jenkins /bin/bash
You have now entered into the docker container, this you can see by something like jenkins#e7b23bad10aa:/$ in your terminal. The hash after the # will for sure differ.
Create the key
jenkins#e7b23bad10aa:/$ ssh-keygen
Press enter on all questions until you get the prompt back
Copy the key to your computer. From within the docker container your computer is 172.17.0.1 should you wonder.
jenkins#e7b23bad10aa:/$ ssh-copy-id user#172.17.0.1
user = your username and 172.17.0.1 is the ip address to your computer from within the docker container.
You will have to type your password at this point.
Now lets try to complete the loop by ssh-ing to your computer from within the docker container.
jenkins#e7b23bad10aa:/$ ssh user#172.17.0.1
This time you should not need to enter you password. If you do, something went wrong and you have to try again.
You will now be in your computers home folder. Try ls and have a look.
Do not stop here since we have a chain of ssh shells that we need to get out of.
$ exit
jenkins#e7b23bad10aa:/$ exit
Right! Now we are back and ready to continue.
Install your Jenkins
You will find your local Jenkins in your browser at http://localhost:8787.
First time you point your browser to your local Jenkins your will be greated with a Installation Wizard.
Defaults are fine, do make sure you install the pipeline plugin during the setup though.
Setup your jenkins
It is very important that you activate matrix based security on http://localhost:8787/configureSecurity and give yourself all rights by adding yourself to the matrix and tick all the boxes. (There is a tick-all-boxes icon on the far right)
Select Jenkins’ own user database as the Security Realm
Select Matrix-based security in the Authorization section
Write your username in the field User/group to add: and click on the [ Add ] button
In the table above your username should pop up with a people icon next to it. If it is crossed over you typed your username incorrectly.
Go to the far right of the table and click on the tick-all-button or manually tick all the boxes in your row.
Please verify that the checkbox Prevent Cross Site Request Forgery exploits is unchecked. (Since this Jenkins is only reachable from your computer this isn't such a big deal)
Click on [ Save ] and log out of Jenkins and in again just to make sure it works.
If it doesn't you have to start over from the beginning and emptying the /opt/docker/jenkins/jenkins_home folder before restarting
Add the git user
We need to allow our git hook to login to our local Jenkins with minimal rights. Just to see and build jobs is sufficient. Therefore we create a user called git with password login.
Direct your browser to http://localhost:8787/securityRealm/addUser and add git as username and login as password.
Click on [ Create User ].
Add the rights to the git user
Go to the http://localhost:8787/configureSecurity page in your browser. Add the git user to the matrix:
Write git in the field User/group to add: and click on [ Add ]
Now it is time to check the boxes for minimal rights to the git user. Only these are needed:
overall:read
job:build
job:discover
job:read
Make sure that the Prevent Cross Site Request Forgery exploits checkbox is unchecked and click on [ Save ]
Create the pipeline project
We assume we have the username user and our git enabled project with the Jenkinsfile in it is called project and is located at /home/user/projects/project
In your http://localhost:8787 Jenkins add a new pipeline project. I named it hookpipeline for reference.
Click on New Item in the Jenkins menu
Name the project hookpipeline
Click on Pipeline
Click [ OK ]
Tick the checkbox Poll SCM in the Build Triggers section. Leave the Schedule empty.
In the Pipeline section:
select Pipeline script from SCM
in the Repository URL field enter user#172.17.0.1:projects/project/.git
in the Script Path field enter Jenkinsfile
Save the hookpipeline project
Build the hookpipeline manually once, this is needed for the Poll SCM to start working.
Create the git hook
Go to the /home/user/projects/project/.git/hooks folder and create a file called post-commit that contains this:
#!/bin/sh
BRANCHNAME=$(git rev-parse --abbrev-ref HEAD)
MASTERBRANCH='master'
curl -XPOST -u git:login http://localhost:8787/job/hookpipeline/build
echo "Build triggered successfully on branch: $BRANCHNAME"
Make this file executable:
$ chmod +x /home/user/projects/project/.git/hooks/post-commit
Test the post-commit hook:
$ /home/user/projects/project/.git/hooks/post-commit
Check in Jenkins if your hookpipeline project was triggered.
Finally make some arbitrary change to your project, add the changes and do a commit. This will now trigger the pipeline in your local Jenkins.
Happy Days!
TL;DR
Jenkins Pipeline Unit testing framework
Jenkinsfile Runner
Long Version
Jenkins Pipeline testing becomes more and more of a pain. Unlike the classic declarative job configuration approach where the user was limited to what the UI exposed the new Jenkins Pipeline is a full fledged programming language for the build process where you mix the declarative part with your own code. As good developers we want to have some unit tests for this kind of code as well.
There are three steps you should follow when developing Jenkins Pipelines. The step 1. should cover 80% of the uses cases.
Do as much as possible in build scripts (eg. Maven, Gradle, Gulp etc.). Then in your pipeline scripts just calls the build tasks in the right order. The build pipeline just orchestrates and executes the build tasks but does not have any major logic that needs a special testing.
If the previous rule can't be fully applied then move over to Pipeline Shared libraries where you can develop and test custom logic on its own and integrate them into the pipeline.
If all of the above fails you, you can try one of those libraries that came up recently (March-2017). Jenkins Pipeline Unit testing framework or pipelineUnit (examples). Since 2018 there is also Jenkinsfile Runner, a package to execution Jenkins pipelines from a command line tool.
Examples
The pipelineUnit GitHub repo contains some Spock examples on how to use Jenkins Pipeline Unit testing framework
Jenkins has a 'Replay' feature, which enables you to quickly replay a job without updating sources:
At the moment of writing (end of July 2017) with the Blue Ocean plugin you can check the syntax of a declarative pipeline directly in the visual pipeline editor. The editor, works from the Blue Ocean UI when you click "configure" only for github projects (this is a known issue and they are working to make it work also on git etc).
But, as explained in this question you can open the editor browsing to:
[Jenkins URL]/blue/organizations/jenkins/pipeline-editor/
Then click in the middle of the page, and press Ctrl+S, this will open a textarea where you can paste a pipeline declarative script. When you click on Update, if there is a syntax error, the editor will let you know where the syntax error is. Like in this screenshot:
If there is no syntax error, the textarea will close and the page will visualize your pipeline. Don't worry it won't save anything (if it's a github project it would commit the Jenkinsfile change).
I'm new to Jenkins and this is quite helpful, without this I had to commit a Jenkinsfile many times, till it works (very annoying!). Hope this helps. Cheers.
A bit late to the party, but that's why I wrote jenny, a small reimplementation of some core Jenkinsfile steps. (https://github.com/bmustiata/jenny)
In my development setup – missing a proper Groovy editor – a great deal of Jenkinsfile issues originates from simple syntax errors. To tackle this issue, you can validate the Jenkinsfile against your Jenkins instance (running at $JENKINS_HTTP_URL):
curl -X POST -H $(curl '$JENKINS_HTTP_URL/crumbIssuer/api/xml?xpath=concat(//crumbRequestField,":",//crumb)') -F "jenkinsfile=<Jenkinsfile" $JENKINS_HTTP_URL/pipeline-model-converter/validate
The above command is a slightly modified version from
https://github.com/jenkinsci/pipeline-model-definition-plugin/wiki/Validating-(or-linting)-a-Declarative-Jenkinsfile-from-the-command-line
As far as i know this Pipeline Plugin is the "Engine" of the new Jenkinsfile mechanics, so im quite positive you could use this to locally test your scripts.
Im not sure if there is any additional steps needed when you copy it into a Jenkinsfile, however the syntax etc should be exactly the same.
Edit: Found the reference on the "engine", check this feature description, last paragraph, first entry.
For simplicity, you can create a Jenkinsfile at the root of the git repository, similar to the below example 'Jenkinsfile' based on the groovy syntax of the declarative pipeline.
pipeline {
agent any
stages {
stage('Build the Project') {
steps {
git 'https://github.com/jaikrgupta/CarthageAPI-1.0.git'
echo pwd()
sh 'ls -alrt'
sh 'pip install -r requirements.txt'
sh 'python app.py &'
echo "Build stage gets finished here"
}
}
stage('Test') {
steps {
sh 'chmod 777 ./scripts/test-script.sh'
sh './scripts/test-script.sh'
sh 'cat ./test-reports/test_script.log'
echo "Test stage gets finished here"
}
}
}
https://github.com/jaikrgupta/CarthageAPI-1.0.git
You can now set up a new item in Jenkins as a Pipeline job.
Select the Definition as Pipeline script from SCM and Git for the SCM option.
Paste the project's git repo link in the Repository URL and Jenkinsfile in the script name box.
Then click on the lightweight checkout option and save the project.
So whenever you pushed a commit to the git repo, you can always test the changes running the Build Now every time in Jenkins.
Please follow the instructions in the below visuals for easy setup a Jenkins Pipeline's job.
Aside from the Replay feature that others already mentioned (ditto on its usefulness!), I found the following to be useful as well:
Create a test Pipeline job where you can type in Pipeline code or point to your repo/branch of a Jenkinsfile to quickly test out something. For more accurate testing, use a Multibranch Pipeline that points to your own fork where you can quickly make changes and commit without affecting prod. Stuff like BRANCH_NAME env is only available in Multibranch.
Since Jenkinsfile is Groovy code, simply invoke it with "groovy Jenkinsfile" to validate basic syntax.
Put your SSH key into your Jenkins profile, then use the declarative linter as follows:
ssh jenkins.hostname.here declarative-linter < Jenkinsfile
This will do a static analysis on your Jenkinsfile. In the editor of your choice, define a keyboard shortcut that runs that command automatically. In Visual Studio Code, which is what I use, go to Tasks > Configure Tasks, then use the following JSON to create a Validate Jenkinsfile command:
{
"version": "2.0.0",
"tasks": [
{
"label": "Validate Jenkinsfile",
"type": "shell",
"command": "ssh jenkins.hostname declarative-linter < ${file}"
}
]
}
You can just validate your pipeline to find out syntax issues. Jenkins has nice API for Jenkisfile validation - https://jenkins_url/pipeline-model-converter/validate
Using curl and passing your .Jenkinsfile, you will get syntax check instantly
curl --user username:password -X POST -F "jenkinsfile=<jenkinsfile" https://jenkins_url/pipeline-model-converter/validate
You can add this workflow to editors:
VS Code
Sublime Text
Using the VS Code Jenkins Jack extension, you can have a way to test your Jenkinsfiles without use the git push way, from your local files to a local or remote running Jenkins. And you will have the running log of the job inside VS Code, the ability to create jobs in Jenkins and more staff. I hope this help to more people looking for a way to develop Jenkinsfiles.
i am using replay future , to do some update and run quickly .
With some limitations and for scripted pipelines I use this solution:
Pipeline job with an inlined groovy script:
node('master') {
stage('Run!') {
def script = load('...you job file...')
}
}
Jenkinsfile for testing have same structure as for lesfurets:
def execute() {
... main job code here ...
}
execute()
This is a short solution that lets me test Pipeline code very quickly:
pipeline {
agent any
options {
skipDefaultCheckout true
timestamps()
}
parameters {
text(name: 'SCRIPT', defaultValue: params.SCRIPT,
description: 'Groovy script')
}
stages {
stage("main") {
steps {
script {
writeFile file: 'script.groovy',
text: params.SCRIPT
def groovyScript = load 'script.groovy'
echo "Return value: " + groovyScript
}
} // steps
} // stage
} // stages
} // pipeline
skipDefaultCheckout true because we do not need the files in this tool git repository.
defaultValue: params.SCRIPT sets the default to the latest execution. If used by just one user, it allows for a very quick cycle of short tests.
The given script is written to a file, and loaded and with load.
With this setup I can test everything I can do inside my other Jenkinsfiles, including using shared libraries.
Is there a way to specify a hook in the single repository?
Now we have specified the hook in the "/etc/mercurial/hgrc" file, but every time it builds twice, and it builds for each commit in each repository.
So we want to specify a build per repository.
This is how we implemented the hook:
[hooks]
changegroup = curl --silent http://jenkins:8080/job/ourProject/build
It's on a Ubuntu server.
Select the Poll SCM option under Build Triggers.
Make sure that schedule form is empty.
You should be creating in the .hg directory, /home/user/mercurial/.hg/hgrc and add hooks as:
[hooks]
commit.jenkins = wget -q http://localhost:8080/mercurial/notifyCommit?url=file:///home/user/mercurial > /dev/null
incoming.jenkins = wget -q http://localhost:8080/mercurial/notifyCommit?url=file:///home/user/mercurial > /dev/null
You should make sure that
Your Jenkins project doesn't poll
You use the proper notifyCommit URLs for your Mercurial hooks: https://wiki.jenkins-ci.org/display/JENKINS/Mercurial+Plugin
Ok, I found what I looked for (I'm the bounty; my case is Mercurial with a specific branch).
In the main/origin repository, place a hook with your desired build script. Pregroupchange is to maintain the incoming changes. I have a rhodecode installed on the main repository and itself has its own hooks.
In this way, I still trigger Jenkins and still have the changes afther the trigger for rhodecode push notifications and others.
[hooks]
pregroupchange = /path/to/script.extention
In the script, place your desired actions, also a trigger for Jenkins. Don't forget to enable in Jenkins:Job:Configure:Build Triggers:checkbox Trigger builds remotely + put here your desired_token (for my case: Mercurial).
Because you can't trigger only to a specific branch in Mercurial, I found the branch name in this way. Also, to trigger from a remote script, you need to give in Jenkins read permission for anonymous overall, or create a specific user with credentials and put them into the trigger URL.
Bash example:
#!/bin/bash
BRANCH_NAME=`hg tip --template "{branch}"`
if [ $BRANCH_NAME = "branch_name" ]; then
curl --silent http://jenkins_domain:port/path/to/job?token=desired_token
fi
For the original question:
In this way you only execute one build, for a desired branch. Hooks are meant only for the main repository in case you work with multiple clones and multiple developers. You may have your local hooks, but don't trigger Jenkins from you local, for every developer. Trigger Jenkins only from the main repository when a push came (commit, incoming, and groupchange). Your local hooks are for other things, like email, logs, configuration, etc.
I have configured jenkins with gerrit trigger plugin to validate every commit we push to gerrit.
I am expecting this trigger to include my latest change with original repo and make a build.
But, it is cloning only repo project and compiling without my change.
Below is my configuration settings for gerrit trigger in jenkins.
Refspec: $GERRIT_REFSPEC
Branches to build: $GERRIT_BRANCH
Build trigger: Gerrit event
Trigger on: patch set created
Gerrit project: added project and branch
Below is the build output message
Triggered by Gerrit: http://ci-test1/22
Building on master in workspace /var/lib/jenkins/jobs/Build_Adserver_4.7/workspace
Checkout:workspace / /var/lib/jenkins/jobs/Build_Adserver_4.7/workspace - hudson.remoting.LocalChannel#733aee56
Using strategy: Default
Last Built Revision: Revision 701a75ef38aa191ac1b806c48e6b3451671888f6 (ads/4.7)
Fetching changes from 1 remote Git repository
Fetching upstream changes from abc
Commencing build of Revision 701a75ef38aa191ac1b806c48e6b3451671888f6 (ads/4.7)
Checking out Revision 701a75ef38aa191ac1b806c48e6b3451671888f6 (ads/4.7)
[workspace] $ /bin/sh -xe /tmp/hudson1375188638196718521.sh
+ echo 'Started Build'
Started Build
+ echo ..................
..................
+ echo 'Build Finished'
Build Finished
Finished: SUCCESS
Here 701a75ef38aa191ac1b806c48e6b3451671888f6 is HEAD of repo branch and 8cbda558adcad4fb7eb714e0b3fb98a6fbf5811c is the SHA-id of my latest change trigged the build.
I verified from jenkins workspace also, it doesn't include my change.
sorry if I am missing any information to mention. Please let me know
please help me if I am missing anything here.
Using Jenkins 1.532.2 Git Client Plugin 1.6.2 Git Plugin 2.0.1 Git Trigger 2.11.0
Here are the steps for configuring the Gerrit Trigger (from memory, hopefully all works fine):
Install the plugin(s) "Gerrit Trigger", "Git Plugin" and "Git Client Plugin"
In the main jenkins config (HOME->Manage Jenkins), click on Gerrit Trigger.
Create the server and configure it. Use "Test Connection" to be sure it works.
At the end, under "Control" press "start" (No idea what that does or if it's actually needed, but I did that).
Go to your project's config (MYPROJECT->Configure)
Check "Gerrit event" under "Build Triggers"
In the newly added menu, select your server, your triggers, etc.
For Gerrit Project I used "Plain" with "MYPROJECT" as pattern
For Branch, I used "Path" and "**" as pattern (builds all branches)
Under "Source Code Management" (up from triggers in my UI), click on "Git"
Set the Repository URL, here $USER matches for me, but otherwise write the correct user $GERRIT_SCHEME://$USER#$GERRIT_HOST:$GERRIT_PORT/$GERRIT_PROJECT
Specify a branch: $GERRIT_BRANCH
Under "Repositories" on the right, click Advanced, for "Refspec" enter $GERRIT_REFSPEC
Click Add right below, and select "Strategy for choosing what to build"
Select "Gerrit Trigger"
Not very intuitive but it should work. I suggest making sure the correct SHA1 Ids are being built.
If run into Error stderr: fatal: Couldn't find remote ref $GERRIT_REFSPEC
You have to change the Choosing Strategy to Gerrit Trigger
Go to the configuration page of your job and then click on the 2nd Advanced button under the git section. Almost at the bottom there is a Choosing Strategy that you will need to change to Gerrit Trigger
This will cause Git to fetch the correct version for your build
Fixing small issues in Lewis answer, change the values to the following to ensure the latest SHA1 is built.
branch: $GERRIT_REFSPEC
REFSPEC: $GERRIT_REFSPEC:$GERRIT_REFSPEC
I am using Jenkins 2.15 and faced the Issue and got resolved with following settings.
In Git Advances add Refspec : $GERRIT_REFSPEC
Branches to build : $GERRIT_BRANCH.
In Addititional behaviors section select Strategy for choosing what to build and select gerrit Trigger.
Using Travis-CI, is it possible to trigger a rebuild without pushing a new commit to GitHub?
Use case: A build fails due to an externality. The source is actually correct. It would build OK and pass if simply re-run.
For instance, an apt-get fails due to a package server being down, but the server is back up again. However the build status is "stuck" at "failed" until a new commit is pushed.
Is there some way to nudge Travis-CI to do another build, other than pushing a "dummy" commit?
If you have write access to the repo: On the build's detail screen, there is a button ↻ Restart Build. Also under "More Options" there is a trigger build menu item.
Note: Browser extensions like Ghostery may prevent the restart button from being displayed. Try disabling the extension or white-listing Travis CI.
Note2: If .travis.yml configuration has changed in the upstream, clicking rebuild button will run travis with old configuration. To apply upstream changes for travis configuration one has to add commit to PR or to close / reopen it.
If you've sent a pull request: You can close the PR then open it again. This will trigger a new build.
Restart Build:
Trigger Build:
If you open the Settings tab for the repository on GitHub, click on Integrations & services, find Travis CI and click Edit, you should see a Test Service button. This will trigger a build.
I know you said without pushing a commit, but something that is handy, if you are working on a branch other than master, is to commit an empty commit.
git commit --allow-empty -m "Trigger"
You can rebase in the end and remove squash/remove the empty commits and works across all git hooks :)
I have found another way of forcing re-run CI builds and other triggers:
Run git commit --amend --no-edit without any changes. This will recreate the last commit in the current branch.
git push --force-with-lease origin pr-branch.
If you have new project on GitHub which has .travis.yml, but was never tested, you can run tests without commit this way:
enable testing in Travis CI setings
open project page on GitHub
open settings -> webhooks and services
find Travis CI in services and press edit button
press "Test service"
You can do this using the Travis CLI. As described in the documentation, first install the CLI tool, then:
travis login --org --auto
travis token
You can keep this token in an environment variable TRAVIS_TOKEN, as long as the file you keep it in is not version-controlled somewhere public.
I use this function to submit triggers:
function travis_trigger() {
local org=$1 && shift
local repo=$1 && shift
local branch=${1:-master} && shift
body="{
\"request\": {
\"branch\": \"${branch}\"
}
}"
curl -s -X POST \
-H "Content-Type: application/json" \
-H "Accept: application/json" \
-H "Travis-API-Version: 3" \
-H "Authorization: token $TRAVIS_TOKEN" \
-d "$body" \
"https://api.travis-ci.org/repo/${org}%2F${repo}/requests"
}
Travis now offers a way to trigger a "custom" build from their web UI. Look for the "More Options" menu button on the right side near the top of your project's page.
You'll then be presented with a dialog box in which you can choose the branch and customize the configuration:
At the time I'm writing this it is in beta, and appears to be slightly buggy (but I expect they'll get the problems ironed out soon).
If you install the Travis CI Client you can use travis restart <job#> to manually re-run a build from the console. You can find the last job# for a branch using travis show <branch>
travis show master
travis restart 48 #use Job number without .1
travis logs master
UPDATE: Sadly it looks like this doesn't start a new build using the latest commit, but instead just restarts a previous build using the previous state of the repo.
If the build never occurred (perhaps you didn't get the Pull-Request build switch set to on in time), you can mark the Pull Request on Github as closed then mark it as opened and a new build will be triggered.
I should mention here that we now have a means of triggering a new build on the web. See https://blog.travis-ci.com/2017-08-24-trigger-custom-build for details.
TL;DR
Click on "More options", and choose "Trigger build".
I just triggered the tests on a pull request to be re-run by clicking 'update branch' here:
Here's what worked for me to trigger a rebuild on a PR that Dependabot had opened, but failed due to errors in .travis.yml:
Close the PR
Wait for Dependabot to comment ("OK, I won't notify you again about this release, but will get in touch when a new version is available."). It will remove its branch.
Restore the branch Dependabot removed (something like dependabot/cargo/tempfile-3.0.4).
Open the PR again
Please make sure to Log In to Travis first. The rebuild button doesn't appear until you're logged in. I know this is obvious, but someone just tripped on it as well ;-)
sometimes it happens that server do made some mistakes.
try log out/sign in and everything might be right then.
(Yes it happened this afternoon to me.)
Simlpy close and re-open the PR if you do not have the write access.