Currently, before making the changes in the .travis.yml file we are showing a long message with all the details of what will happen to the file. It includes an example of how the file could look after the command runs:
From Gustavo:
"The example here feels a bit dirty [...]. We should simply state that it will be modified and why. Not how or with which content. We know for sure that this file is under revision control, and may be reviewed if desired, and the developer will also need to commit acknowledging the change explicitly before it's put in use."
Currently, before making the changes in the .travis.yml file we are showing a long message with all the details of what will happen to the file. It includes an example of how the file could look after the command runs:
See the example below::
sudo: required travis_ snapcraft. cfg snapcraft. cfg -d
skip_cleanup: true
snapcraft && snapcraft push *.snap --release edge"
services:
- docker
after_success:
- openssl aes-256-cbc -K <travis-key> -iv <travis-iv>
-in .snapcraft/
-out .snapcraft/
deploy:
Provider: script
script: docker run -v $(pwd):$(pwd) -t ubuntu:xenial sh -c
"apt update -qq && apt install snapcraft -y && cd $(pwd) &&
on:
branch: master
From Gustavo:
"The example here feels a bit dirty [...]. We should simply state that it will be modified and why. Not how or with which content. We know for sure that this file is under revision control, and may be reviewed if desired, and the developer will also need to commit acknowledging the change explicitly before it's put in use."