翻译强力驱动I would like to use Travis CI for my open-source project. The issue that Travis doesn't provide any ways to publish produced artifacts (though, they have this in their future plans).
What are workarounds to publish/upload artifacts somewhere? I'm allowed to execute any scripts on a CI machine.
Simple upload will work, but there is security issue: anyone will be able to upload something in the same way as all sources are public.
The "github releases uploading" feature is announced recently. It officially supports everything that is needed. See http://docs.travis-ci.com/user/deployment/releases/
GitHub releases step-by-step
The method was mentioned at https://stackoverflow.com/a/24100779/895245, and is poorly documented at: https://docs.travis-ci.com/user/deployment/releases/ , so here goes a more detailed step-by-step.
It uploads artifacts to GitHub releases https://github.com/ which exist for every Git tag you push.
Get a Personal Access Token under https://github.com/settings/tokens
Only enable "public_repo" access for public repositories, "repo" for private.
Save the token somewhere as you can only see it once.
Install the travis gem:
gem install travis # See: https://stackoverflow.com/a/33119804/895245 gem update --system Then cd into your repository and:
travis encrypt but more recently people have reported that travis encrypt -r githubusername/repositoryname --org is needed instead, see: https://github.com/travis-ci/travis-ci/issues/8128
This will produce an output like:
secure: "" Note down the large encrypted token.
Use a .travis.yml as follows:
script: # This command generates a release.zip file. - make dist deploy: provider: releases api_key: secure: "" file: 'release.zip' skip_cleanup: true on: tags What happens is that Travis replaces every something: secure: with just something: as explained at: http://docs.travis-ci.com/user/encryption-keys/
This is safe because only authorized pushes by you can decrypt the string, so if a malicious user tries to make a pull request to get your string, it would should just show the encrypted string.
Now whenever you push a commit with a tag, Travis will upload release.zip to the release:
git commit -m 1.0 git tag -m 1.0 1.0 git push --tags If you had already pushed the commit and the tag after, you might have to click the "Restart build" button on the Travis UI for it to upload.
https://stackoverflow.com/a/38037626/895245 has some screenshots of the process.
Alternative method: environment variable
Instead of an encrypted string, we could also use a hidden environment variable.
On the Travis settings for the repository https://travis-ci.org/ create an environment variable:
GITHUB_API_KEY=and make sure to mark "Display value in build log" as "Off", and use:
api_key: '$GITHUB_API_KEY' While this will not show on logs for pull requests, this method is riskier, as you could my mistake list the environment of a build.
The upside is that this method is simpler to understand.
A simple example of mine that uploads images generated from Gnuplot to GitHub releases:
Question about GitHub Pages deployment: How to publish to Github Pages from Travis CI?
If your project is based on Github - likely with Travis - then the easiest way is to check in the generated artifacts under the gh-pages branch. See more on Github.
How to do that depends a lot on the used build system. With maven, you can use maven-scm-plugin - you can find an example here.
EDIT: You can find a full example here: https://github.com/tonnymadsen/ui-bindings/blob/master/com.rcpcompany.updatesite/pom.xml
So first you have to be sure that you try to deploy release artifacts. So make tag first in Github. To do it manually:
Then in the .travis.yml file add the following configuration. For gradle users
language: java jdk: - oraclejdk7 sudo: required before_install: - chmod +x gradlew script: - ./gradlew clean build -i --continue deploy: provider: releases api_key: ${api_key} file: "build/libs/Project.jar" skip_cleanup: true on: all_branches: true tags: true Here api_key value is Travis Ci environment variable. Which points to Github api_key.
file is the build artifact produced from the build. Which we want to be deployed to gitHub.
on: all_branches: true tags: true is mandatory configuration for tags to be deployed.
No you have to get the api_key from github:
When you trigger new build the artifact will be deployed. 
Update: Github disable the Download API now, so below answer is idea.
My solution is using "secure environment variables" provided by travis-ci and "Github repo Download API" with related script
Each repo in Github has download pages, it is also the good place to publish your artifacts, and it has related "Repo Download API" http://developer.github.com/v3/repos/downloads/
github-upload.rb from https://github.com/wereHamster/ghup to manage the GitHub API.In the end, in the .travis-ci.yml it looks like below
env: global: - secure: "qkE5/TVKQV/+xBEW5M7ayWMMtFwhu44rQb9zh3n0LH4CkVb+b748lOuW3htc\nXfnXU8aGzOsQBeCJZQstfzsHFPkll+xfhk38cFqNQp7tpMo/AOZIkqd2AIUL\n0bgaFD+1kFAxKTu02m11xzkDNw6FuHMVvoMEQu/fo115i2YmWHo=" after_script: - ./github-upload.rb sdcamp.zh.pdf larrycai/sdcamp --description "generated by travis-ci, $TRAVIS_JOB_ID" --force --name sdcamp.zh.snapshot.pdf --skip-ssl-verification -t $GITHUB_TOKEN see my detail blog: http://larrycaiyu.com/blog/2012/10/25/publish-the-artifacts-inside-travis-ci-to-github/
I realize this is an older question, but I'd like to add another solution to the mix that I believe to be better than the ones discussed thus far.
The OP is interested in publishing artifacts from Travis-CI. I recommend using https://bintray.com/ with either an organization, or your own personal account (both work, but in the case of a github org, it might make more sense to have an organization that matches it, and published artifacts from that github org go to it's matching bintray org).
The reason for this is because of what bintray offers and it's support for open source projects. I recommend you take a look here at their overview: http://www.jfrog.com/bintray/
You can also link to JCenter, which makes what you publish much easier for anyone else to consume/download/use (via maven, gradle, SBT, etc).
Once you have bintray setup (your account created or an org), you can easily integrate it with travis. For java & maven builds, you can use travis-ci's encrypted variables option to encrypt the ${BINTRAY_USER} and ${BINTRAY_API_KEY}. Then you can set up maven deploy to push releases into bintray. In the maven settings.xml file, you'll just reference the environment variables you encrypted with travis as the user/pass, ie:
my-bintray-id ${env.BINTRAY_USER} ${env.BINTRAY_API_KEY} Next, you'll add the distributionManagement section to your project's pom.xml, something like this:
my-bintray-id https://api.bintray.com/maven/myUserName/myRepoName/my_awesome_project;publish=1 Then you will set up your .travis.yml file to "detect" when there is a release. I've used the first half of the maven release plugin: mvn release:prepare (ignoring the second half -- release:preform) from your local dev box. This will make a tag, bump the version in the pom, etc, on your behalf. What you end up with is a tag of a version (not -SNAPSHOT) in github. This tagged commit makes its way downstream to travis, where your .travis.yml will configure Travis to build & publish.
In your .travis.yml, configure it to test for a TRAVIS_TAG, TRAVIS_PULL_REQUEST, and any other checks you want to make before calling mvn deploy. You would do this on after_success. This way, travis builds all the time, but only runs mvn deploy when it's a tag and meets other conditions you want (like for instance, a JDK8 build). Here's an example .travis.yml:
language: java jdk: - oraclejdk7 - oraclejdk8 after_success: - mvn clean cobertura:cobertura coveralls:report javadoc:jar - test "${TRAVIS_PULL_REQUEST}" == "false" && test "${TRAVIS_TAG}" != "" && mvn deploy --settings travis-settings.xml branches: only: - master # Build tags that match this regex in addition to building the master branch. - /^my_awesome_project-[0-9]+\.[0-9]+\.[0-9]+/ env: global: - secure: cfHTvABEszX79Dhj+u8/3EahMKKpAA2cqh7s3JACtVt5HMEXkkPbeAFlnywO+g4p2kVENcQGbZCiuz2FYBtN3KrIwFQabJE8FtpF57nswPRrmpRL+tWcYtipVC2Mnb4D7o6UR2PiC7g20/9EEWV7OeddXU3fzNBBW+LXkKAL20Ishg/jTDj+DIMFeVU8a6gd+6G2r8rf2jr2PMUeq1lO+eSkm3cjQLjRJN3CNY5GQToV/l1hef732y//6K9prP+H9vbkx+c7KF6W6OsQuXha9hy038J4ZXFWiNZdLUZLytrTcsOdbL2d8qEBv38ycs71kw0eHINMcPbNWYaxWHKeQRIievSPbTqOmm5BSh/keBRQe+aBzKrzw680QcRcnDMFePb1uu9VhpCabu0fBTer/7MENhR/QDoW8g4ydZNqXSWqiJBaYomENhjUF3v/4KzvX5P8bPlVBvgyAAcAzY8+MwLVeZKsJIUAHuS5v6kHSb0F17pvAb1XM+jet92PT/tRh75kVHtwtiPffhCd2/LzjmCLH31CC4WUZDG4OGw/8SbMiGX1Kww1Y9hSp09rQ9ytLaQa1kDa2Nv4syjJRVKWQf3/TS1VLqXBYVZXufY/XtyA0gDV0ZumwNo8ukT5Cnc7hC9oFkRvPkJxvNTzgDWkd6TVUDligxgLQHS/2fZpNo= - secure: cfHTvABEszX79Dhj+u8/3EahMKKpAA2cqh7s3JACtVt5HMEXkkPbeAFlnywO+g4p2kVENcQGbZCiuz2FYBtN3KrIwFQabJE8FtpF57nswPRrmpRL+tWcYtipVC2Mnb4D7o6UR2PiC7g20/9EEWV7OeddXU3fzNBBW+LXkKAL20Ishg/jTDj+DIMFeVU8a6gd+6G2r8rf2jr2PMUeq1lO+eSkm3cjQLjRJN3CNY5GQToV/l1hef732y//6K9prP+H9vbkx+c7KF6W6OsQuXha9hy038J4ZXFWiNZdLUZLytrTcsOdbL2d8qEBv38ycs71kw0eHINMcPbNWYaxWHKeQRIievSPbTqOmm5BSh/keBRQe+aBzKrzw680QcRcnDMFePb1uu9VhpCabu0fBTer/7MENhR/QDoW8g4ydZNqXSWqiJBaYomENhjUF3v/4KzvX5P8bPlVBvgyAAcAzY8+MwLVeZKsJIUAHuS5v6kHSb0F17pvAb1XM+jet92PT/tRh75kVHtwtiPffhCd2/LzjmCLH31CC4WUZDG4OGw/8SbMiGX1Kww1Y9hSp09rQ9ytLaQa1kDa2Nv4syjJRVKWQf3/TS1VLqXBYVZXufY/XtyA0gDV0ZumwNo8ukT5Cnc7hC9oFkRvPkJxvNTzgDWkd6TVUDligxgLQHS/2fZpNo= (The secure's are just a made up example, after you encrypt your bintray user and bintray api key with travis, you'll see something similar in your yaml)
This gets you a full end to end system for publishing artifacts "into the wild" where anyone can then consume and use. You're using a service that is designed from the ground up as an artifact repository (bintray), and you are using Travis in a smart way to check for tags that maven release:prepare produces. All together, you decide when releases are made (mvn release:prepare from your local dev box), and travis gets them to bintray.
Note that there's an existing travis-ci/dpl pull request in github to get tighter integration (travis providers) between Travis and bintray built. This makes it much easier to have travis send artifacts to bintray (releases; bintray wasn't intended to hold SNAPSHOTs, use Artifactory for that instead). Even though github has some support for releases, as of this writing, I believe bintray to be superior in this role, and the right tool to use.
Good luck!
I've put together an example project at https://github.com/vorburger/mvnDeployGitHubTravisCI illustrating how to do this (partially based on Hosting a Maven repository on github). As explained on the linked answer, the basic idea is to prepare a local repository using the maven-deploy-plugin's altDeploymentRepository, and then use the github site-maven-plugin to push your artifacts to GitHub. Connect Travis to GitHub authentication as explained above.
TravisCI now supports releases: https://docs.travis-ci.com/user/deployment/releases/
GitHub removed the Download API, but replaced it with releases: https://github.com/blog/1547-release-your-software
The integration SBT-Travis-Sonatype consists of the following main steps:
I put together a simple instruction on how to integrate SBT with Travis-CI and Sonatype, it is available here and contains the necessary steps from configuring the project plugins to encrypting the files and providing Travis configuration. It is mostly based on John Duffel’s developer blog combined with sbt-pgp reference docs.