How can I set up a build schedule for Travis-CI that is not based around pushing to GitHub? I want to run Selenium tests against my production site nightly. I'm happy with a hacky solution if official support is not present.
Travis-CI's cron jobs feature was implemented in May 2016.
I've launched a self-service app for this: https://nightli.es. Ensures the project is built at least once a day.
I see two options which will give you full control to setup your build schedule.
Using Travis CI command line interface with OS task scheduler or
You may use an external solution such as Tron CI which gives you the chance to schedule as many builds you want for each project that you have on Travis CI. I've been using it for quite a time to run one of my projects twice a day and works just perfectly.
Related
I am Test automation engineer and I have developed my automation code repository to test functional aspect of the product. I want this code to run when any developer pushes feature or bug on the beta environment.
I have built the pipeline on Automation repository, and I am using docker image for selenium and maven for the same. When I push any changes on my repository pipeline triggers but I want this same to happen from different repositories.
One solution I can think of it is Trigger automation pipeline from developer's pipeline through REST API (pipeline-initiated). But this is not a full proof solution as automation pipeline image will not be updated after the changes made by developers.
In short: We have automation tests written in one repo and development code run into one repo. As a part of CI/CD/CT, I want all of these things run automatically and we get the bug free build every time.
You should try Ansible for this scenario. As you already have you docker images . Just wrap it with ansible and use to to trigger automation on different repos push trigger.
I need to create Build Job in travis which triggers 1hourly or 2hourly .
i have seen option in Travis by daily,weekly and monthly.
Please give me advice in the same.
Travis does not offer smaller intervals than daily for their "cron" builds.
To achieve a similar effect you will have to run a cron locally that triggers a new travis build via their api client.
I'm not sure what Travis is, but generally you can use #hourly instead of #daily etc in /etc/crontab, or put your script in /etc/cron.hourly instead of /etc/cron.daily. The locations may be different depending on your Linux distro, but this is how it works in Ubuntu.
I am looking for implementation of CI/CD in to my current project here is what i think will work.
Environment consists of
- Jenkins
- git
- docker
- gradle
- Linux servers
- Sonar
- Ansible.
Each tool will be used as following.
Git:- Developers will push there code to this CVS.
Jenkins:- On detecting Check-in Jenkins will trigger a build and will deploy to one of the server.
Sonar:- will be used for code coverage and will check the code before building the same through Jenkins.
ansible:- ansible will be used to quickly prepare added nodes so that code can be deployed to them.
Docker in case if we need fresh test environments every time we can use docker+ ansible combo for doing the things.
Flow of work will be
User run unit test cases on his machine and commits the code to the server.
Jenkins will pull the code from git and will run sonar on the same and will generate reports.
jenkins will create build and will deploy the same on dev server.
A jenkins job will run and will perform the integration testing on the dev server
Any other automated tests can be run.
Finally builds pushed to next server using Jenkins.
I will use shell commands inside Jenkins to push compiled code from one server to another.
In my this scenario can some one answer me following.
Where will sonar get fit and how to use the same?
I see there are CD tools, cant i push compiled code to the servers using shell scripts written inside the Jenkins jobs to automatically deploy the things? What extra benefits a CD tool provides
Is is wise to create fresh test environment or we can keep using the old one again and again?
Will this complete CI/CD?
can someone share there implementation
You say you plan to use Git. I'll outline a scenario using Git on GitHub
Developers push code changes here as pull requests
The SonarQube GitHub Plugin kicks off an initial analysis of only the code changed in the PR looking for the introduction of new issues (note that coverage and duplications are not included in this check)
Once the PR is merged, Jenkins (in one job or several, depending on your needs)
builds
fires integration tests & any other automated tests
runs SonarQube Scan. Note that this comes last to include integration test results.
pushes build to next server
Note that the ability to break the build when the project doesn't pass the SonarQube Quality Gate you've set up may be desirable in your situation. Unfortunately, it's not available in the current server version: 5.2. It is available in 5.1, and is should return soon.
I'm trying to create two builds in Jenkins - let's call them Setup and Testing. The Setup build should pull dev code from Git and SVN and do the necessary setup on the slave (compile, etc.) to set up our application. It should run only when there are SCM changes. The Testing build should pull automated regression test code from Git, do the necessary setup on the slave to get the tests ready, and run the tests at midnight every night there are SCM changes to the dev code. I do not want the Testing job to run if there are no SCM changes to the dev code.
Here's my problem. I know how to make the Setup build only run when there are SCM changes. I know how to make the Testing build run on a schedule. What I can't seem to figure out is how to make the Setup build trigger the Testing build, but not run the Testing build until midnight. I can only make it run right away when Setup finishes, which isn't what I want (we do have real-time CI acceptance tests that run like this, but our regression suite serves a slightly different purpose).
What I think I'm looking for is a way to pass a flag, like SCM_CHANGES=TRUE, and only run Testing at its scheduled time if (SCM_CHANGES). I may be overlooking a different way of doing this, though - I'm open to suggestions.
Sounds like the BuildResultTrigger Plugin might solve your problem - with it, you could set up the Testing job to monitor the result of the Setup job, with a schedule for midnight, every night.
At midnight it will check if there was a new build of Setup (and the result matches a criteria), and if yes, trigger a new Testing run.
Use case:
CI server polls some VSC repository and runs test suite for each revision. And if two or more revisions were commited, even in a relatively small time interval, I want the CI server to put each of them in queue, run tests for each, store the results, and never run tests again for those commits. And I don't want the CI server to launch jobs in parallel, to avoid performance issues and crashes in case of many simultaneous jobs.
Which CI server is able to handle this?
My additional, less important requirement is that I use Python and it is desirable to use software written in Python, so I looked at the Buildbot project, and I especially want to see reviews for this tool in the matter of is it usable in general and is it capable of replacing most popular solutions like Travis or Jenkins.
I have used jenkins to do this. (with subversion mainly, c/c++ build and also bash/python scripted jobs)
The easiest and default handling of VCS/SCM changes in jenkins is to poll for changes on a set time. A build is triggered if there is any change. More than one commit may be included in build (e.g. if 2 commits are done close together) when using this method. Jenkins shows links back to scm and scm update done as well as showing build logs and you can easily configure build outputs and test result presentation.
https://wiki.jenkins-ci.org/display/JENKINS/Building+a+software+project#Buildingasoftwareproject-Buildsbysourcechanges
What VCS/SCM are you using? Jenkins interfaces to a good few VCS/SCM:
https://wiki.jenkins-ci.org/display/JENKINS/Plugins#Plugins-Sourcecodemanagement
This question answers how to make Jenkins build on every subversion commit:
Jenkins CI: How to trigger builds on SVN commit
TeamCity is free (up to a number of builds and build agents) and feature-rich. It's very easy to install and configure, although it may take some time to find your way through the wealth of options. It is extremely well documented: http://www.jetbrains.com/teamcity/documentation/
It is written in Java but supports many tools natively and others through command-line execution, so you can build anything with it that you want. (I use it mostly for Ruby.) It understands the output of many testing tools; if you're not using one of them maybe yours can emulate their output. It's quite extensible; it has a REST API and a plugin API.
It can be configured to build on each commit, or to build all of the commits that arrived in a given time period, or to trigger in other ways. Docs here: http://confluence.jetbrains.com/display/TCD8/Configuring+VCS+Triggers
By default it starts a single build agent and runs one build at a time on that build agent. You can run more build agents for speed. If you don't want to run more than one build on a machine, only start one build agent on each machine.
I dont want that CI server would launch jobs in parallel to avoid
performance issues and crashes in cases of many simultanious jobs.
In buildbot you can limit the number of running jobs in a salve with max_build parameter or locks
As for Buildbot and Python, you may coordinate parallel builds by configuration, for example:
Modeling Parallel Processes: Steps
svn up
configure
make
make test
make dist
In addition, you can also try using a Triggerable scheduler for your builder which performs steps U,V,W.
From the docs:
The Triggerable scheduler waits to be triggered by a Trigger step (see
Triggering Schedulers) in another build. That step can optionally wait
for the scheduler's builds to complete. This provides two advantages
over Dependent schedulers.
References:
how to lock steps in buildbot
Coordinating Parallel Builds with
Buildbot
There is a Throttle Concurrent Builds Plugin for Jenkins and Hudson. It allows you to specify the number of concurrent builds per job. This is what it says on the plugin page:
It should be noted that Jenkins, by default, never executes the same Job in parallel, so you do not need to actually throttle anything if you go with the default. However, there is the option Execute concurrent builds if necessary, which allows for running the same Job multiple time in parallel, and of course if you use the categories below, you will also be able to restrict multiple Jobs.)
There is also Gitlab CI, a very nice modern Ruby project that uses runners to distribute builds so you could, I guess, limit the number of runners to 1 to get the effect you are after. It's tightly integrated with Gitlab so I don't know how hard it would be to use it as a standalone service.
www.gitlab.com
www.gitlab.com/gitlab-ci
To only run tests once for every revision you can do something like this:
build
post-build
check if the revision of the build is in /tmp/jenkins-test-run
if the revision is in the file skip tests
if the revision is NOT in the file run tests
if we ran the tests then write the ID in /tmp/jenkins-test-run