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://mcmap.net/q/335688/-how-to-publish-artifacts-in-travis-ci, 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/<username>/<repo>/releases 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://mcmap.net/q/339898/-encrypting-files-for-travis-ci-on-ruby-2-2-2-fails-with-quot-private-method-load-39-called-for-psych-module-quot
gem update --system
Then cd into your repository and:
travis encrypt <api-token>
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: "<encrypted-token>"
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: "<encrypted-token>"
file: 'release.zip'
skip_cleanup: true
on:
tags
What happens is that Travis replaces every something: secure: <encrypted-string> with just something: <decrypted-string> 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://mcmap.net/q/335688/-how-to-publish-artifacts-in-travis-ci 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/<me>/<myrepo>/settings create an environment variable:
GITHUB_API_KEY=<token>
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?
travis encrypt -r githubusername/repositoryname --org, see travis issue –
Malposition The "github releases uploading" feature is announced recently. It officially supports everything that is needed. See http://docs.travis-ci.com/user/deployment/releases/
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:
<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.
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.
The first question you should ask yourself is whether you want to publish artifacts from CI builds or whether you want to deploy releases (i.e. to GitHub).
Since there are plenty of answers here regarding uploading releases to GitHub, I will not tackle this topic further.
If you want to get hold of snapshot/CI build artifacts, the easiest way is to have them uploaded to AWS S3. Unfortunately, the documentation for this is a bit rough, especially when you are unexperienced with AWS. So here is what you have to do:
1. Create a AWS IAM user for Travis
To do so, go to https://console.aws.amazon.com/iam/home?#/users and create a new user account for Travis with type Programmatic access. Grant it access to S3 by applying the existing policy AmazonS3FullAccess on the permissions tab.
Once the user is created make sure to copy the Access Key ID as well the secret access key for that user!
2. Create a AWS S3 Bucket for Travis to upload to
That one is pretty straight forward. Only thing to watch out for is to avoid Signature v4-only regions like us-east-2, eu-central-1, etc. (because of https://github.com/travis-ci/artifacts/issues/57). A solid choice is us-east-1, which also happens to be the default expected by Travis and thus saves you a little additional configuration. Of course you can also use an existing bucket that meets this requirement.
3. Add environment variables to Travis CI repository settings
Next, go to the settings for your repository in Travis. Create the following new environment variables:
ARTIFACTS_KEY=(AWS access key id from step 1)
ARTIFACTS_SECRET=(AWS secret access key from step 1)
ARTIFACTS_BUCKET=(S3 bucket name from step 2)
4. Enable artifacts addon
Finally, in your repository add the following lines to the .travis.yml in order to activate the artifacts addon
addons:
artifacts: true
If everything went well, you should see your build artifacts popping up in the S3 bucket. You may want to adjust the paths being scanned and so on, as desecribed in the documentation.
Hope that helps someone or another.
© 2022 - 2024 — McMap. All rights reserved.
artifactsaddon actually accepts. – Iwo