Travis CI originally created two separated platforms to differentiate between private repos / paid (travis-ci.com) and public repos / free (travis-ci.org).
However, as of May 2018, new users and projects (both private and public) should only use travis-ci.com (see official announcement).
Over the next several months, we’ll be migrating all travis-ci.org ...
Aside from pricing model, the two sites are identical.
travis-ci.org is a free service for public open source projects.
travis-ci.com is a paid service for private commercial projects.
From the FAQ page for Travis Pro
Why can’t I find information on pricing on travis-ci.org?
Travis CI is, and always will be, free for open source projects.
In general, there are five main differences between different CI software solutions.
Cost: Is the software open source and free or proprietary? Does your DevOps team already have a budget for software or are you expected to compare free options?
Maintenance: Is the software something you need to host on your own and maintain, or is it being offered as a ...
You need to write some unit tests and set the script variable in your .travis.yml to actually run a file.
By default, Travis CI runs the command phpunit without any arguments. When this happens, phpunit doesn't know what you're asking it to do, and shows a help message, then exits with error code 2 (i.e. non-zero, which indicates an error occurred).
The easiest method is to have Eclipse generate an Ant build script for you.
Right click on your project in the Package Explorer and select Export in the context menu. Choose the export type General -> Ant Buildfiles and click Next.
On the next screen, make sure your project is selected. You can keep leave the options on their default settings. Click Finish ...
The SCM system you use can be essential in making your CI choice.
Using a private/intranet solution, for example, pretty much excludes CircleCI and TravisCI as these only support cloud-based GitHub and/or Bitbucket.
Jenkins has plugins supporting many SCM systems out there, see Which SCM tools does Jenkins support?. But using a less popular or a wrapped/...
Instead of using Travis' deployment features, build the deployment logic in to your normal "test" script(s). For a PaaS this might be as simple as pushing to another git remote if all tests pass, but the sky is the limit.
Azure has a robust CI/CD pipeline which is much easier to use than CodeDeploy on AWS. It is called Build/Release pipelines under Azure DevOps. It allows you to configure multiple environments with build and release (deployment) stages for each. It also allows for easy configuration and interoperability with Azure Webapps/VMs and other resources available on ...
Travis CI supports deployment on branch release by using the following syntax:
The problem is that GitHub does not support it.
As per GitHub Releases Uploading page at Travis CI:
Please note that deploying GitHub Releases works only for tags, not for branches.
For GitHub the only workaround is to push tags (e.g. git ...
Try LFTP that has commands to mirror or parallel copy. LFTP can run over many protocols.
The likely problem you have is that you are transfering a lot of data from a build service to a single vm over the Internet. Enterprises use the same tools and protocols but they pay for more bandwidth else ensure that their builds and deploy happens within the same ...
Where are the travis-ci servers located? Does travis-ci leverage AWS EC2?
According to this documentation, the servers are located in the USA and AWS EC2 is used as well.
Your code, depending on which platform or language runtime you're
using, is run on virtualized servers running in:
Amazon EC2 datacenters in Ashburn, VA, USA,
One could use conditional builds https://docs.travis-ci.com/user/conditional-builds-stages-jobs/
If code is merged into master one could decide to deploy code to production, but I personally prefer a human intervention by a Product Owner.
if: branch = master
- name: deploy
# require the branch name to be master
You can find the IP addresses of the Travis build machines here. If you add the IP addresses of the Travis infrastructure you use to your whitelisted IPs in Cloud SQL it should work. Keep in mind these IP addresses can change in the future though.
Your idea will work. The organization I work for maintains some open source examples how to do deploy to AWS using a pipeline. In comparison we use GitLab for the purpose. Instead of Travis we use GitLab Runner. You configure it using the file .gitlab-ci.yml which runs the tests and deploy the AWS Lambda to dev, test and production environment every time a ...
OK - found the solution myself. It's a kind of tricky one. Even though my project is written in F#, I still have to set
in my .travis.yml file. That's a bit counter-intuitive, but I must admit that it's written in the doc, so can't really blame anyone.
Use environment variables on your host that are read by your docker-compose.yml file. There are a couple ways to accomplish this. One way is to create a .env file on the host that contains your variables. Docker Compose will read these variables and apply them to your configuration.
Alternatively, or in conjunction with a .env file, you can set ...
One typical solution is to add a deployment task to your Travis CI pipeline. This task may, for example, run a command on your Ubuntu VPS to pull and run the :latest image. You could use any number of techniques to accomplish this: a CM tool like Ansible or Chef, a Bash script or simply SSH.
Travis CI documentation has some information on deployment ...
Not sure this helps you directly, but one option is to build the application within your CI build and push the (versioned) binaries/packages into an artifact repositorie like Sonatype Nexus or JFrog Artifactory.
Your build would then, in a later step pull these binaries from the target machine/from within the droplet.
There are many packaging formats, ...
If you're married to Docker Hub, you could use a webhook to notify Travis of the need to start it's job.
However, I solve this problem using Quay.io - it has the robot account (you refer to "service account") you need. It also has a richer set of notifications.
You could maintain your current workflow using webhooks to
create the repository on Quay or ...
This functionality is built straight into travis. Have a look at here.
Secondly you should not need to specify a branch as part of your make script as travis will triggered on a specific branch and therefore that revision would already be checked out.
You should try CI / CD like:
Codeship ( free tier, and totally free for open source projects )
Openshift, as @JamesKnott mention, but this one is a full PaaS, so it is meant to host your app too.
Hope it helps
The updated deploy script in the question supports the following workflow (and requires this server setup):
Create a feature branch and push commits to it
Each push deploys the code to the staging server
Review the code with merge request (feature branch --> master)
After merging to master, create a new merge request (master --> production)
Due to Github ...
Found the answer to my own question, straight from travis support
Thanks for writing in. Yes indeed, on our container based
infrastructure, ICMP is not possible. Could you speficy sudo:
required in the .travis.yml and see if it brings improvement?