How to publish artifacts in Travis CI?

Question

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 futu

Answer 1

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.

Answer 2

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

Answer 3

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

Answer 4

The "github releases uploading" feature is announced recently. It officially supports everything that is needed. See http://docs.travis-ci.com/user/deployment/releases/

Answer 5

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:

1. Go to Personal Access Tokens

2. Choose Generate new token

3. Select appropriate scopes for the api_key
4. Copy the generated api_key
5. Go to the Travis Ci and add environment variable. For that purpose choose Settings
   6. Paste the generated api_key

When you trigger new build the artifact will be deployed.

Answer 6

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.

Use Bintray:

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).

For Java + Maven:

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:

  <servers>
    <server>
      <id>my-bintray-id</id>
      <username>${env.BINTRAY_USER}</username>
      <password>${env.BINTRAY_API_KEY}</password>
    </server>
  </servers>

Next, you'll add the distributionManagement section to your project's pom.xml, something like this:

<distributionManagement>
    <repository>
        <id>my-bintray-id</id>
        <url>https://api.bintray.com/maven/myUserName/myRepoName/my_awesome_project;publish=1</url>
    </repository>
</distributionManagement>

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.

Other

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!