Merge branch 'master' into ci-profile_page

Author: iriberri

.travis.yml

@@ -15,6 +15,10 @@ cache:
   directories:
     - vendor/bundle
     - node_modules
+addons:
+  apt:
+    packages:
+      - libxml2-utils
 deploy:
   provider: heroku
   api_key:
@@ -36,3 +40,4 @@ install:
   - bundle install --deployment
 script:
   - bundle exec rake test
+  - xmllint --noout _site/feed.build-env-updates.xml

_data/deployments.yml

@@ -37,3 +37,4 @@ Scalingo: "/user/deployment/scalingo/"
 Script: "/user/deployment/script/"
 Surge.sh: "/user/deployment/surge/"
 TestFairy: "/user/deployment/testfairy/"
+Ubuntu Snap Store: "/user/deployment/snaps/"

feed.build-env-updates.xml

@@ -9,7 +9,7 @@ layout: null
 		<link>https://travis-ci.com</link>
 		<atom:link href="http://docs.travis-ci.com/feed.build-env-updates.xml" rel="self" type="application/rss+xml" />
 		{% for page in site.pages %}
-		{% if page.category == "build_env_updates" %}
+		{% if page.category == "mac_build_env_updates" or page.category == "linux_build_env_updates" %}
 			<item>
 				<title>{{ page.title | xml_escape }}</title>
 				<description>{{ page.content | xml_escape }}</description>

user/deployment/codedeploy.md

@@ -61,6 +61,7 @@ You can explicitly specify the branch to deploy from with the **on** option:
       secret_access_key: "YOUR AWS SECRET KEY"
       bucket: "S3 Bucket"
       key: latest/MyApp.zip
+      bundle_type: zip
       application: MyApp
       deployment_group: MyDeploymentGroup
       on:
@@ -77,6 +78,7 @@ Alternatively, you can also configure Travis CI to deploy from all branches:
       secret_access_key: "YOUR AWS SECRET KEY"
       bucket: "S3 Bucket"
       key: latest/MyApp.zip
+      bundle_type: zip
       application: MyApp
       deployment_group: MyDeploymentGroup
       on:
@@ -164,6 +166,7 @@ You can explicitly specify the AWS region to deploy to with the **region** optio
       secret_access_key: "YOUR AWS SECRET KEY"
       bucket: "S3 Bucket"
       key: latest/MyApp.zip
+      bundle_type: zip
       application: MyApp
       deployment_group: MyDeploymentGroup
       region: us-west-1

user/deployment/pypi.md

@@ -73,7 +73,8 @@ Alternatively, you can also configure Travis CI to release from all branches:
 ```yaml
 deploy:
   provider: pypi
-  api_key: ...
+  user: ...
+  password: ...
   on:
     all_branches: true
 ```

user/deployment/rubygems.md

@@ -160,6 +160,12 @@ deploy:
 You can deploy only when certain conditions are met.
 See [Conditional Releases with `on:`](/user/deployment#Conditional-Releases-with-on%3A).
 
+### Gem must be registered beforehand
+
+Note that the gem you upload must be registered beforehand.
+If the gem does not exist on the host to which it is uploaded, deployment will fail.
+See [this GitHub issue](https://github.com/travis-ci/dpl/issues/574) for details.
+
 ### Running commands before and after release
 
 Sometimes you want to run commands before or after releasing a gem. You can use the `before_deploy` and `after_deploy` stages for this. These will only be triggered if Travis CI is actually pushing a release.

user/deployment/snaps.md

@@ -0,0 +1,38 @@
+---
+title: Ubuntu Snap Store
+layout: en
+permalink: /user/deployment/snaps/
+---
+
+Travis CI can automate the continuous delivery to the [Snaps](https://snapcraft.io) Store.
+
+Snaps are a new packaging and delivery system for Ubuntu, Debian, Fedora, openSuse and other [Linux distros](https://snapcraft.io/docs/core/install). Snaps are secure, they bundle all their dependencies and they are designed to be part of the upstream development workflow in a seamless way. This means that no distro maintainers are involved, and that the delivery to the store can be fully automated. The snaps installed in the users' machines are auto-updated, so a few hours after you push a new snap to the store, all your users will get the most recent version.
+
+To automate continuous delivery of snaps to the Ubuntu store:
+
+1. [Encrypt](https://docs.travis-ci.com/user/encrypting-files) your snapcraft credentials with Travis CI
+2. Add the encrypted credentials to the repository where you have the `snapcraft.yaml` metadata for your package.
+3.  Run `snapcraft` and `snapcraft push` in your `.travis.yml`:
+
+    ```yaml
+    deploy:
+      skip_cleanup: true
+      provider: script
+      script: docker run -v $(pwd):$(pwd) -w $(pwd) snapcore/snapcraft sh -c "apt update && snapcraft && snapcraft push *.snap --release edge"
+      on:
+        branch: master
+    ```
+
+The `snapcraft enable-ci travis` command will assist you getting the credential, encrypting it and adding the right script to the deploy section of your `.travis.yml` file. Here is a [tutorial that will guide you setting up the continuous delivery from Travis CI](https://tutorials.ubuntu.com/tutorial/continuous-snap-delivery-from-travis-ci#0) on your project.
+
+Note that the `edge` channel is intended for crowdtesting with your community of early adopters. With this deployment script in Travis, every time a pull request lands into the master branch, a new snap will be published to edge. Your testers can install it in any of the supported Linux distros with:
+
+```bash
+sudo snap install my-snap-name --edge
+```
+
+After that, they will be always ready to provide early feedback and help making a more stable release.
+
+You can adjust the Travis script and the `snapcraft` calls to fit your development process. For example, you could install the snap and run user acceptance tests before releasing to edge, to make sure that there are no regressions in master. Also, there are three other channels in the store: `beta`, `candidate` and `stable`. You can run different tests suites with Travis for each channel on your way to stable.
+
+There are plenty of [tutorials](https://tutorials.ubuntu.com/) and [videos](https://www.youtube.com/snapcraftio) that will help you packaging your project as a snap.

user/languages/javascript-with-nodejs.md

@@ -265,7 +265,7 @@ language: node_js
 node_js:
   - "7"
 before_install:
-  - "curl -L https://raw.githubusercontent.com/arunoda/travis-ci-laika/master/configure.sh | /bin/sh"
+  - "curl -L https://raw.githubusercontent.com/arunoda/travis-ci-laika/6a3a7afc21be99f1afedbd2856d060a02755de6d/configure.sh | /bin/sh"
 services:
   - mongodb
 env:
@@ -286,7 +286,7 @@ language: node_js
 node_js:
   - "7"
 before_install:
-  - "curl -L https://raw.githubusercontent.com/arunoda/travis-ci-meteor-packages/master/configure.sh | /bin/sh"
+  - "curl -L https://raw.githubusercontent.com/arunoda/travis-ci-meteor-packages/dca8e51fafd60d9e5a8285b07ca34a63f22a5ed4/configure.sh | /bin/sh"
 before_script:
   - "export PATH=$HOME/.meteor:$PATH"
 ```

user/languages/nix.md

@@ -32,15 +32,21 @@ The default channel for `nixpkgs` will be `nixpkgs-unstable`.
 
 The following command line tools are available in the Nix environment:
 
-- nix-env
+- nix
 - nix-build
+- nix-channel
+- nix-collect-garbage
+- nix-copy-closure
+- nix-daemon
+- nix-env
+- nix-instantiate
+- nix-prefetch-url
 - nix-shell
 - nix-store
-- nix-channel
 
 ## Default Nix Version
 
-Currently, only version "1.11.2" of Nix is provided. In the future, it may be possible to configure different versions with `.travis.yml`.
+This installs the current version of Nix using https://nixos.org/nix/install. In the future, it may be possible to configure different versions with `.travis.yml`.
 
 ## Default Target
 

user/languages/rust.md

@@ -99,7 +99,7 @@ cargo test --verbose
 You always can always configure different comands if you need to. For example,
 if your project is a
 [workspace](http://doc.crates.io/manifest.html#the-workspace-section), you
-should pass `-all` to the build commands to build and test all of the member
+should pass `--all` to the build commands to build and test all of the member
 crates:
 
 ```yaml

user/running-build-in-debug-mode.md

@@ -47,8 +47,14 @@ $ curl -s -X POST \
   https://api.travis-ci.org/job/${id}/debug
 ```
 
+(Note the literal word `token` must be present before the actual authorization token.)
+
 For private repositories, the API endpoint is `https://api.travis-ci.com/job/${id}/debug`.
 
+#### Finding the job ID
+
+The `${id}` is a job ID, not a build ID. For example, the ID `248927956` in the URL [`https://travis-ci.org/travis-ci/docs-travis-ci-com/builds/248927956`](https://travis-ci.org/travis-ci/docs-travis-ci-com/builds/248927956) is a build ID. To obtain the corresponding job ID, click the _View config_ button on that page, and the URL will change into [`https://travis-ci.org/travis-ci/docs-travis-ci-com/jobs/248927957/config`](https://travis-ci.org/travis-ci/docs-travis-ci-com/jobs/248927957/config), showing the job ID `248927957`. Alternatively, you can obtain job IDs corresponding to a build ID [via the API](https://docs.travis-ci.com/api/#builds).
+
 #### Echoing debug session's output to the logs
 
 To show any command input and output you see while connected to the VM running in the debug