I am hitting the curl command which starts the jenkins job, but i also wanted to get the running logs of build is is possible with the help of curl command.
Take a look at
Jenkins REST API to get job and job console log
and
https://serverfault.com/questions/888176/how-to-trigger-jenkins-job-via-curl-command-remotely
Generally, you have to start job get handler and periodically call API
The environment BUILD_URL represents the current build url, thus you can get the current build log as following in job post action
curl -u 'jenkins_user:jenkins_pwd' -k "${BUILD_URL}consoleText"
I have some doubts about the correct configuration of Jenkins to ensure the continuous integration of a Drupal project but I arrive at some contradictions.
Let me explain: the deployment, after all, consists in executing:
cd / path / to / web / root
pull from git
drush config:import
drush cache:rebuild
The tests are launched with the command
../vendor/bin/phpunit --verbose --log-junit ../tests_output/phpunit.xml -c ../phpunit.xml
The contradiction is that I do not understand when to run the tests.
Before the pull does not make sense because the last changes are missing, after the pull if any test goes wrong I should be able to restore the situation before the pull (but I'm not sure it's a safe action).
I'm trying to run the tests directly in the workspace of jenkins and to do this I also created a separate database, but at the moment I get the error:
Drupal\Tests\field_example\Functional\TextWidgetTest::testSingleValueField
Behat\Mink\Exception\ElementNotFoundException: Button with id|name|label|value "Log in" not found
What could be the best strategy to follow?
So, your order seems ok - pull first then run tests.
However, you can have 2 Jenkins jobs. First runs, your tasks. 2nd runs ONLY if your first job completes without failure.
There are ways to get exit status from scripts - see following plugins/notes about that.
How to mark Jenkins builds as SUCCESS only on specific error exit values (other than 0)?
How to mark a build unstable in Jenkins when running shell scripts
I have a CI pipeline in Bitbucket which is building, testing and deploying an application.
The thing is that after the deploy I want to run selenium tests.
Selenium tests are in an another repository in Bitbucket and they have their own pipeline.
Is there a trigger step in the Bitbucket pipeline to trigger a pipeline when a previous one has finished?
I do not want to do a fake push to the test repository to trigger those tests.
The most "correct" way I can think of doing this is to use the Bitbucket REST API to manually trigger a pipeline on the other repository, after your deployment completes.
There are several examples of how to create a pipeline here: https://developer.atlassian.com/bitbucket/api/2/reference/resource/repositories/%7Bworkspace%7D/%7Brepo_slug%7D/pipelines/#post
Copy + pasting the first example. How to trigger a pipeline for the latest commit on master:
$ curl -X POST -is -u username:password \
-H 'Content-Type: application/json' \
https://api.bitbucket.org/2.0/repositories/jeroendr/meat-demo2/pipelines/ \
-d '
{
"target": {
"ref_type": "branch",
"type": "pipeline_ref_target",
"ref_name": "master"
}
}'
according to their official documentation there is no "easy way" to do that, cause the job are isolated in scope of one repository, yet you can achieve your task in following way:
create docker image with minimum required setup for execution of your tests inside
upload to docker hub (or some other repo if you have such)
use docker image in last step of you pipeline after deploy to execute tests
Try out official component Bitbucket pipeline trigger: https://bitbucket.org/product/features/pipelines/integrations?p=atlassian/trigger-pipeline
You can run in after deploy step
script:
- pipe: atlassian/trigger-pipeline:4.1.7
variables:
BITBUCKET_USERNAME: $BITBUCKET_USERNAME
BITBUCKET_APP_PASSWORD: $BITBUCKET_APP_PASSWORD
REPOSITORY: 'your-awesome-repo'
ACCOUNT: 'teams-in-space'
#BigGinDaHouse I did something more or less like you say.
My step is built on top of docker image with headless chrome, npm and git.
I did follow the steps below:
I have set private key for the remote repo in the original repo. Encoded base 64. documentation. The public key is being set into the remote repo in SSH Access option in bitbucket menu.
In the pipeline step I am decoding it and setting it to a file. I am also changing its permission to be 400.
I am adding this Key inside the docker image. ssh-add
Then I am able to do a git clone followed by npm install and npm test
NOTE: The entry.sh is because I am starting the headless browser.
- step:
image: kimy82/headless-selenium-npm-git
script:
- echo $key_in_env_variable_in_bitbucket | base64 --decode > priv_key
- chmod 400 ./priv_key
- eval `ssh-agent -s`
- ssh-agent $(ssh-add priv_key; git clone git#bitbucket.org:project.git)
- cd project
- nohup bash /usr/bin/entry.sh >> out.log &
- npm install
- npm test
Top answers (this and this) are correct, they work.
Just adding that we found out (after a LOT of trial and error) that the user executing the pipeline must have WRITE permissions on the repo where the pipeline is invoked (even though his app password permissions were set to "WRITE" for repos and pipelines...)
Also, this works for executing pipelines in Bitbucket's cloud or on-premise, through local runners.
(Answering as I am lacking reputation for commenting)
I have a requirement where i need to trigger the build jobs remotely using curl command. I am unable to pass the branch/tag name as a parameter to trigger the build.
I used the below command :
& $CURLEXE -k -X POST $dst_job_url --user username:token --data-urlencode json='{"parameters": [{"name":"branch","branch":"branches"}]}'
If i run the above command it was triggers the build for the trunk ( default ).
You omitted the URL, so it's hard to be certain. Jenkins has two urls for building: "build" and "buildWithParameters". If you're not using buildWithParameters, switching to it will probably help.
See:
How to trigger Jenkins builds remotely and to pass parameters
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.