I currently have a Github repo with two folders, backend and frontend. In each folders there's an app I need to deploy to a given provider. I'm using TravisCI to auto-deploy.
I'd like to be able to do different before_deploy steps for each provider. Is there a way to do that with TravisCI?
Here's what my .travis.yml looks like so far:
language: java
jdk:
- oraclejdk8
before_install:
- cd backend
before_deploy:
- cd backend
deploy:
- provider: cloudcontrol
email: "CLOUDCONTROL EMAIL"
password: "CLOUDCONTROL PASSWORD"
deployment: "APP_NAME/DEP_NAME"
- provider: heroku
api_key:
secure: "My_API_KEY"
app: MYAPP
Related
I'm trying to set up automatic deploy on heroku with travis. I get this error when travis try to deploy:
API request failed.
Message: Invalid credentials provided.
Reference:
failed to deploy
This is my travis file:
jobs:
include:
- language: python
python:
- "3.6"
install:
- pip install -r Deployment/requirements.txt
script:
- python -c "print ('Testing some script')"
branches:
only:
- master
- develop
before_deploy:
- cd Deployment
deploy:
- provider: heroku
skip_cleanup: true
api_key:
secure: b3AVdCtJ2e/+Gu1...
app:
master: motorent-deploy
develop: motorent-apitest
- language: android
dist: trusty
env:
global:
- ANDROID_API_LEVEL=29
- ANDROID_BUILD_TOOLS_VERSION=29.0.3
- extra-google-google_play_services
- extra-google-m2repository
- extra-android-m2repository
- addon-google_apis-google-$ANDROID_API_LEVEL
android:
licenses:
- 'android-sdk-preview-license-.+'
- 'android-sdk-license-.+'
- 'google-gdk-license-.+'
components:
- tools
- platform-tools
- android-$ANDROID_API_LEVEL
- build-tools-$ANDROID_BUILD_TOOLS_VERSION
- extra-google-google_play_services
- extra-google-m2repository
- extra-android-m2repository
- addon-google_apis-google-$ANDROID_API_LEVEL
addons:
apt:
packages:
ant
before_install:
- touch $HOME/.android/repositories.cfg
- yes | sdkmanager "platforms;android-29"
- yes | sdkmanager "build-tools;29.0.3"
before_script:
- cd AndroidApp
- chmod +x gradlew
script:
- ./gradlew build check
As you can see I have two differents projects in the same repository, but it's not important, because the android test works well. What doesn't work is the deploy of Flask project. The solutions that I have found talk about the need to encrypt the api_key. I have tested it with Travis encrypt $(heroku auth:token) but it doesn't work either.
I've been trying to find the error for a long time but I don't know what it can be.
I had the same error.
Here are steps that I performed to fix it.
Firstly I tried the command: heroku auth:token
but the output was:
› Warning: token will expire 06/06/2021
› Use heroku authorizations:create to generate a long-term token
Then I tried the command: heroku authorizations:create
One line from the output contained Token: <created_heroku_auth_token>
I took the value of it (<created_heroku_auth_token>)
and I went to
https://travis-ci.org/github/<my_github_user>/<my_repo>/settings
where I created new environment variable:
HEROKU_AUTH_TOKEN with value of my <created_heroku_auth_token>
Then in my .travis.yml I changed value of api_key to:
api_key: $HEROKU_AUTH_TOKEN
After pushing this change, the deployment to heroku went fine.
We're trying to deploy our lambda using serverless on BitBucket pipelines, but we're running into an issue when running the serverless config credentials command. This issue also happens in docker containers, and locally on our machines.
This is the command we're running:
serverless config credentials --stage staging --provider aws --key $AWS_ACCESS_KEY --secret $AWS_ACCESS_SECRET
And it gives us the error:
Error: Profile default does not exist
The profile is defined in our serverless.yml file. If we rename the serverless file before running the command, it works, and then we can then put the serverless.yml file back and successfully deploy.
e.g.
- mv serverless.yml serverless.old
- serverless config credentials --stage beta --provider aws --key $AWS_ACCESS_KEY --secret $AWS_ACCESS_SECRET
- mv serverless.old serverless.yml
We've tried adding the --profile default switch on there, but it makes no difference.
It's worth noting that this wasn't an issue until we started to use the SSM Parameter Store within the serverless file, the moment we added that, it started giving us the Profile default does not exist error.
serverless.yml (partial)
service: our-service
provider:
name: aws
runtime: nodejs12.x
region: eu-west-1
profile: default
stage: ${opt:stage, 'dev'}
iamRoleStatements:
- Effect: 'Allow'
Action: 'ssm:GetParameter'
Resource:
- 'arn:aws:ssm:eu-west-1:0000000000:parameter/our-service-launchdarkly-key-dev'
- 'arn:aws:ssm:eu-west-1:0000000000:parameter/our-service-launchdarkly-key-beta'
- 'arn:aws:ssm:eu-west-1:0000000000:parameter/our-service-launchdarkly-key-staging'
- 'arn:aws:ssm:eu-west-1:0000000000:parameter/our-service-launchdarkly-key-live'
- Effect: 'Allow'
Action: 'kms:Decrypt'
Resource:
- 'arn:aws:kms:eu-west-1:0000000000:key/alias/aws/ssm'
environment:
LAUNCH_DARKLY_SDK_KEY: ${self:custom.launchDarklySdkKey.${self:provider.stage}}
custom:
stages:
- dev
- beta
- staging
- live
launchDarklySdkKey:
dev: ${ssm:/our-service-launchdarkly-key-dev~true}
beta: ${ssm:/our-service-launchdarkly-key-beta~true}
staging: ${ssm:/our-service-launchdarkly-key-staging~true}
live: ${ssm:/our-service-launchdarkly-key-live~true}
plugins:
- serverless-offline
- serverless-stage-manager
...
TLDR: serverless config credentials only works when serverless.yml isn't present, otherwise it complains about profile default not existing, only an issue when using SSM Param store in the serverless file.
The profile attribute in your serverless.yaml refers to saved credentials in ~/.aws/credentials. If a [default] entry is not present in that file, serverless will complain. I can think of 2 possible solutions to this:
Try removing profile from your serverless.yaml completely and using environment variables only.
Leave profile: default in your serverless.yaml but set the credentials in ~/.aws/credentials like this:
[default]
aws_access_key_id=***************
aws_secret_access_key=***************
If you go with #2, you don't have to run serverless config credentials anymore.
This my .travis.yml file. I am trying to automate deployment to aws-codedeploy.
language: node_js
node_js:
- 7.10.0
services:
- mongodb
env:
- PORT=6655 IP="localhost" NODE_ENV="test"
script:
- npm start &
- sleep 25
- npm test
deploy:
provider: codedeploy
access_key_id:
secure: $Access_Key_Id
secret_access_key:
secure: $Access_Key_Secret
revision_type: github
application: Blog
deployment_group: Ayush-Bahuguna
region: us-east-2
after_deploy:
- "./build.sh"
Here build.sh is a shell script that generates the build files
cd /var/www/cms
sudo yarn install
npm run build-prod
And here is .gitignore file
node_modules/
client/dashboard/dist/
client/blog/dist/
The issue is that, even though travis-ci build succeeds, and after_deploy runs successfully, no build files are generated on the aws ec2 instance where my project is hosted.
Are you able to see any deployment created on your AWS CodeDeploy console? And are your able to see the deployment status? If there is a deployment created, but failed, you can try to see the reason why it failed. Even though the deployment succeeded, it doesn't equal to all instances are deployed depends on the deployment configuration: http://docs.aws.amazon.com/codedeploy/latest/userguide/deployment-configurations.html.
Thanks,
Binbin
Here is my travis.yml. I am trying to figure out how to run when I push to any branch. Under app, I am forced to put the specific branch that I am working on. I want to use all_branches: true. If I use all_branche: true, then what is the key under app? I want to use a generic word like stage, but I am thinking that it looking for a specific branch name, because when I tried stage, I got a 404. Also, does the app key, in this case feature/travisCi have to match the branch? The docs aren't very clear, so I am looking for a bit deeper explanation.
language: node_js
node_js:
- node
- '6'
before_deploy:
- npm run build
deploy:
provider: heroku
api_key:
secure: ... secret key
app:
feature/travisCi: morning-engine-36163
on:
repo: hipshot/dashboardfe
branch: feature/travisCi
The branch specification for the app key is only required if you'd like to deploy each of your branches to a different application in Heroku.
For example, if you have a master branch which you want to deploy to your production Heroku app, and you have a staging branch which is the one you might like to deploy to your staging Heroku app, then you can do as follows:
language: node_js
node_js:
- node
- '6'
before_deploy:
- npm run build
deploy:
provider: heroku
api_key:
secure: ... secret key
app:
master: heroku_app_name_for_production
staging: heroku_app_name_for_staging
on:
all_branches: true
However, if you only have a Heroku app and you want to deploy there any changes in any of your branches, it's not needed to specify the branch: heroku_app section under app, and you can simply use:
language: node_js
node_js:
- node
- '6'
before_deploy:
- npm run build
deploy:
provider: heroku
api_key:
secure: ... secret key
app: your_heroku_app_name
on:
all_branches: true
Another typical scenario would be to only deploy to Heroku the changes to your master branch. To do so:
language: node_js
node_js:
- node
- '6'
before_deploy:
- npm run build
deploy:
provider: heroku
api_key:
secure: ... secret key
app: your_heroku_app_name
on:
branch: master
Getting back to your specific example, if you're going to restrict the deploy to your feature/travisCi branch, this should work:
language: node_js
node_js:
- node
- '6'
before_deploy:
- npm run build
deploy:
provider: heroku
api_key:
secure: ... secret key
app: morning-engine-36163
on:
branch: feature/travisCi
In our project repository we have an appveyor.yml which is setup for our .NET web applications (with things like assembly patching, nuget restore, etc.). If everything succeeds, our application is deployed to a staging and production environment. The .NET solution is located in repo/src/.
In the same repository we also create our HTML templates located in repo/frontend/. We would like to do a deploy of these HTML-files to a FTP host. This Frontend configuration should be run before the other configurations, but logically fails on assembly_info and nuget restore when no .NET solution is created.
Is it possible to create an appveyor configuration which can deploy our Frontend configuration to FTP and optionally continue with the Debug and Release configurations when a .NET solution is available?
Our configuration file this far:
version: 1.0.0.{build}
branches:
only:
- develop
- /release\/\d+.\d+.\d+/
- master
image: Visual Studio 2015
matrix:
fast_finish: true # set this flag to immediately finish build once one of the jobs fails.
allow_failures:
- platform: x86
configuration: Debug
- platform: x86
configuration: Release
assembly_info:
patch: true
file: AssemblyInfo.*
assembly_version: "{version}"
assembly_file_version: "{version}"
assembly_informational_version: "{version}"
nuget:
account_feed: true
configuration:
- Frontend
- Debug
- Release
build:
publish_wap: true
verbosity: minimal
before_build:
- cmd: nuget restore src\ProjectName.Web.sln
test: off
artifacts:
- path: frontend/dist/
name: frontenddist
deploy:
- provider: FTP
host: 0.0.0.0
protocol: ftp
username: username
password:
secure: password
folder: frontend-test
application: frontenddist
beta: true
on:
branch: develop
configuration: frontend
- provider: Environment
name: ProjectName.Development
remove_files: true
on:
branch: develop
configuration: debug
- provider: Environment
name: ProjectName.Production
remove_files: false
on:
branch: master
configuration: release
notifications:
- provider: Slack
incoming_webhook: # removed for stackoverflow example
on_build_success: true
on_build_failure: true
on_build_status_changed: false
Answer in AppVeyor forum discussion