Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Elaborate on how non-tag builds and GitHub Releases interact #1383

Merged
merged 6 commits into from Nov 22, 2017
@@ -4,7 +4,9 @@ layout: en
swiftypetags: 'skip_cleanup'
---

### Supported Providers
<div id="toc"></div>

## Supported Providers

Continuous Deployment to the following providers is supported:

@@ -13,7 +15,7 @@ Continuous Deployment to the following providers is supported:
To deploy to a custom or unsupported provider, use the [after-success build
stage](/user/deployment/custom/) or [script provider](/user/deployment/script).

### Uploading Files
## Uploading Files

When deploying files to a provider, prevent Travis CI from resetting your
working directory and deleting all changes made during the build ( `git stash
@@ -25,7 +27,7 @@ deploy:
```
{: data-file=".travis.yml"}

### Deploying to Multiple Providers
## Deploying to Multiple Providers

Deploying to multiple providers is possible by adding the different providers
to the `deploy` section as a list. For example, if you want to deploy to both
@@ -42,9 +44,9 @@ deploy:
```
{: data-file=".travis.yml"}

### Conditional Releases with `on:`
## Conditional Releases with `on:`

Deployment can be controlled by setting the `on:` for each deployment provider.
Set your build to deploy only in specific circumstances by configuring the `on:` key for any deployment provider.

```yaml
deploy:
@@ -59,27 +61,36 @@ deploy:
```
{: data-file=".travis.yml"}

When all conditions specified in the `on:` section are met, deployment for this
provider will be performed.
When *all* conditions specified in the `on:` section are met, your build will deploy.

Use the following options to configure conditional deployment:

* `repo`: in the form `owner_name/repo_name`. Deploy only when the build occurs on a particular repository. For example

Common options are:
```yaml
on:
repo: travis-ci/dpl
```

1. **`repo`** Slug of your repository (in form: `owner_name/repo_name`, e.g., `travis-ci/dpl`).
* `branch`: name of the branch.
If omitted, this defaults to the `app`-specific branch, or `master`. If the branch name is not known ahead of time, you can specify
`all_branches: true` *instead of* `branch: ` and use other conditions to control your deployment.

2. **`branch`** Name of the branch. If omitted, this defaults to the `app`-specific branch, or `master`. If the branch name is not known ahead of time, you can specify
`all_branches: true` *instead of* `branch: **` and use other conditions to control your deployment.
* `jdk`, `node`, `perl`, `php`, `python`, `ruby`, `scala`, `go`: for language runtimes that support multiple versions,
you can limit the deployment to happen only on the job that matches a specific version.

3. **`jdk`**, **`node`**, **`perl`**, **`php`**, **`python`**, **`ruby`**, **`scala`**, **`go`**: For language runtimes that support multiple versions,
you can limit the deployment to happen only on the job that matches the desired version.
* `condition`: deploy when *a single* bash condition evaluates to `true`. This must be a string value, and is equivalant to `if [[ <condition> ]]; then <deploy>; fi`. For example, `$CC = gcc`.

4. **`condition`**: You may set bash condition with this option.
This must be a string value, which will be pasted into a bash expression of the form
`if [[ <condition> ]]; then <deploy>; fi`
It can be complex, but there can be only one. For example, `$CC = gcc`.
* `tags` can be `true`, `false` or any other string:

5. **`tags`**: When set to `true`, the application is deployed when a tag is applied to the commit. This causes the `branch` condition to be ignored.
* `tags: true`: deployment is triggered if and only if `$TRAVIS_TAG` is set.
Depending on your workflow, you may set `$TRAVIS_TAG` explicitly, even if this is
a non-tag build when it was initiated. This causes the `branch` condition to be ignored.
* `tags: false`: deployment is triggered if and only if `$TRAVIS_TAG` is empty.
This also causes the `branch` condition to be ignored.
* When `tags` is not set, or set to any other value, `$TRAVIS_TAG` is ignored, and the `branch` condition is considered, if it is set.

#### Examples of Conditional Releases using `on:`
### Examples of Conditional Deployment

This example deploys to Appfog only from the `staging` branch when the test has run on Node.js version 0.11.

@@ -122,7 +133,7 @@ deploy:
```
{: data-file=".travis.yml"}

### Adding a Provider
### Adding a deployment provider

We are working on adding support for other PaaS providers. If you host your application with a provider not listed here and you would like to have Travis CI automatically deploy your application, please [get in touch](mailto:support@travis-ci.com).

@@ -135,6 +146,6 @@ deploy:
```
{: data-file=".travis.yml"}

### Pull Requests
## Pull Requests

Note that pull request builds skip the deployment step altogether.
@@ -6,8 +6,6 @@ layout: en

Travis CI can automatically upload assets from your [`$TRAVIS_BUILD_DIR`](/user/environment-variables/#Default-Environment-Variables) to git tags on your GitHub repository.

**Note that deploying GitHub Releases works only for tags, not for branches.**

For a minimal configuration, add the following to your `.travis.yml`:

```yaml
@@ -23,7 +21,24 @@ deploy:

> Make sure you have `skip_cleanup` set to `true`, otherwise Travis CI will delete all the files created during the build, which will probably delete what you are trying to upload.
The `on: tags: true` section at the end of the `.travis.yml` above is required to make sure that your tags get deployed.
GitHub Releases uses git tags. If the build commit does not have any tags, one will be created in the form of `untagged-*`, where `*` is a random hex string.

If this is not what you want, either set your build to deploy only when the build already has a tag using `on.tags: true` as shown in the previous example `.travis.yml`, or tag the commit with `git tag` in `before_deploy`:

```yaml
before_deploy:
# Set up git user name and tag this commit
- git config --local user.name "YOUR GIT USER NAME"
- git config --local user.email "YOUR GIT USER EMAIL"
- git tag "$(date +'%Y%m%d%H%M%S')-$(git log --format=%h -1)"
deploy:
provider: releases
api_key: "GITHUB OAUTH TOKEN"
file: "FILE TO UPLOAD"
skip_cleanup: true
```
{: data-file=".travis.yml"}


If you need to overwrite existing files, add `overwrite: true` to the `deploy` section of your `.travis.yml`.

@@ -39,15 +54,10 @@ Or, if you're using a private repository:
travis setup releases --pro
```

If you are using the [`branches.only` property](/user/customizing-the-build#Building-Specific-Branches), remember that when you push a tag, the [`$TRAVIS_BRANCH` property](/user/environment-variables/#Default-Environment-Variables) contains the name of the tag. As a result, edit the `branches.only` property to add the names of the tags you might push in the future. You can use a regular expression if you have formalized names. For example, if your release tags look like `v1.3.15`, use the following configuration:

```yaml
branches:
only:
- master
- /^v\d+(\.\d+)+$/
```
## `on.tags` condition

When working with GitHub Releases, it is important to understand how the deployment is triggered
with [the `tags` condition](/user/deployment/#Conditional-Releases-with-on%3A).


## Authenticating with an OAuth token
ProTip! Use n and p to navigate between commits in a pull request.
You can’t perform that action at this time.