I tried using "cap rollback" but I get the following error:
$ cap rollback
the task `rollback' does not exist
Is there some additional setup that I need to do to get rollbacks to work?
Just found the answer here http://github.com/leehambley/railsless-deploy:
cap deploy:rollback
If you're using different environments (e.g. staging, production) using the multistage gem (e.g. you have require 'capistrano/ext/multistage' in your deploy.rb file) then Capistrano defaults to staging. So, to roll back a production environment you would do:
cap production deploy:rollback
and, assuming you've got the defaults set, this would roll back staging:
cap deploy:rollback
Worth knowing if you're using different environments and wondering why it's not working for production.
simple roll back:
$ cap deploy:rollback
rollback to specific version:
$ cap deploy:rollback -s previous_release= [path to previous release under releases folder ]
Actually it is
cap deploy:rollback:code
deploy:rollback may rollback to a previous revision, not necessarily a previously deployed revision.
Related
I'd like to fix a bug in a Perl repository (now owned by me, I just submitted some pull requests), but at the moment it's failing its Travis CI tests (before my pull requests).
My goal is to be able to run Travis CI tests locally starting from the repository's .travis.yml.
Note that I'm totally new to Travis CI.
Following other's solutions that pointed to this FAQ (http://web.archive.org/web/20180929150027/https://docs.travis-ci.com/user/common-build-problems/#troubleshooting-locally-in-a-docker-image), that as you can see is no longer officially available in travis-ci.com, I tried:
sudo docker pull travisci/ci-amethyst:packer-1512508255-986baf0
sudo docker run --name travis-debug -dit travisci/ci-amethyst:packer-1512508255-986baf0 /sbin/init
sudo docker exec -it travis-debug bash -l
From the container:
su - travis
git clone https://github.com/{user}/{repo}.git
Now I don't know how to build the bash script to run the tests, as the last two steps (manually install dependencies / run your Travis CI build) looks cryptic (I don't know how to run the build, and possibly lead to lack of reproducibily (if I install dependencies manually, how do I know I'll get the same results as the cloud test?)
I tried starting from the procedure described here (https://github.com/travis-ci/travis-build
), one error is ´Could not locate Gemfile or .bundle/ directory´, but I probably need some missing steps.
For what its worth, I think you are going at it from the wrong angle.
Travis is just running your stuff remotely. Instead of bringing Travis to your machine, you need to make your tests pass locally first - cryptic or not - there is no way around it, especially if you are going to own this repo.
Another reason I am recommending this, is that - as you have already witnessed - the develop-debug-fix cycle is much lengthier when you rely on something to test your code remotely.
It has been my experience that your .travis.yml should be super simple, since it just runs one or two scripts or commands that can comfortably run locally.
If you are comfortable with Docker, I would consider building a local Dockerfile with all the dependencies, and bring your tests to work in your docker environment. Once you succeeded with this step, asking Travis to do the same (run tests in a docker) is trivial.
Not sure if it is the answer you were looking for, but it was too long for a comment.
I'm trying to setup a release to three environments, Dev, QA, Production, and working through failures, mainly IIS Application errors.
Right now, I'm trying to get my QA environment setup. Unfortunately it is a lot of trial and error to get the release to pass. When it fails, I have to go edit the release, edit my tasks for the QA environment, then start a release all over.
My problem is, I'm just trying to get this setup, these aren't "real" releases. However I'm wasting time after each configuration change having it deploy code to my "Dev" environment. I already know those steps work.
Is there a way I can skip an environment, and select a specific environment I want it to release code too?
As Daniel said that you can choose the environments which you want to deploy manually when start a release.
You also can set Manual only for the environment directly:
You also can enable Artifact filters with specific tags or branch (git), then just the artifact meet the filters, the release can deploy to this environment.
When you start a release you're presented with a list of all of the environments and their deployment conditions. Simple set all of the environments to "Manual". Then when you create the release, you can choose the environment to which you wish to deploy from the "Deploy" menu.
I have a capistrano task that uses "run_locally" to compass compile/compress my css files and then upload them to the server.
Is it going to be smart and run that on the git branch that's getting deployed, or will it just run on the branch that I currently have in my working copy?
I'd want it to run on the branch that's getting deployed regardless of what I have checked locally. If it's not smart about this would I instead need to run_locally a git checkout on the branch that's getting deployed before running the compile command?
It runs on you current local code. So it matters what code is checked out there. As you mentioned you can try to ensure that you run the version you are going to deploy.
Better would be to do the compilation work on the server.
In other rails projects, I'd have a local database.yml and in source code repository only commit the database.sample file. When deploying, a capistrano script that would symlink a shared version of database.yml to all the releases.
When deploying to heroku, git is used and they seem to override database.yml altogether and do something internal.
That's all fine and good for database.yml, but what if I have s3 configurations in config/s3.yml. And I'm putting my project on github so I don't want to commit the s3.yml where everyone can see my credentials. It'd rather commit a sample s3.sample which people will override with their own settings, and keep a local s3.yml file uncommitted in my working directory.
what is the best way to handle this?
Heroku have some guidance on this -
http://devcenter.heroku.com/articles/config-vars
An alternative solution is to create a new local-branch where you modify .gitignore so secret-file can be pushed to heroku.
DON'T push this branch to your Github repo.
To push non-master branch to heroku, use:
git push heroku secret-branch:master
More info can be found on:
https://devcenter.heroku.com/articles/multiple-environments#advanced-linking-local-branches-to-remote-apps
Use heroku run bash and then ls to check whether your secret-file have been pushed on to heroku or not
Store the s3 credentials in environment variables.
$ cd myapp
$ heroku config:add S3_KEY=8N029N81 S3_SECRET=9s83109d3+583493190
Adding config vars:
S3_KEY => 8N029N81
S3_SECRET => 9s83109d3+583493190
Restarting app...done.
In your app:
AWS::S3::Base.establish_connection!(
:access_key_id => ENV['S3_KEY'],
:secret_access_key => ENV['S3_SECRET']
)
See the Heroku Config Vars documentation which explain development setup etc.
If using Rails 4.1 beta, try the heroku_secrets gem, from https://github.com/alexpeattie/heroku_secrets:
gem 'heroku_secrets', github: 'alexpeattie/heroku_secrets'
This lets you store secret keys in Rails 4.1's config/secrets.yml (which is not checked in to source control) and then just run
rake heroku:secrets RAILS_ENV=production
to make its contents available to heroku (it parses your secrets.yml file and pushes everything in it to heroku as environment variables, per the heroku best practice docs).
You can also check out the Figaro gem.
I solved this by building the credentials from env variables during the build time, and write it to where I need it to be before the slug is created.
Some usecase specific info that you can probably translate to your situation:
I'm deploying a Node project, and in the package.json in the postinstall script I call "bash create-secret.sh". Since postinstall is performed before the slug is created, the file will be added to the slug.
I had to use a bash script because I had some trouble printing strings that contained newlines that had to be printed correctly, and I wasn't able to get it done with Node. Probably just me not being skilled enough, but maybe you run into a similar problem.
Looking into this with Heroku + Build & Deploy-time Secrets. It seems like it's not something Heroku supports. This means for a rails app, there is no way other than committing BUNDLE_GITHUB__COM for example to get from private repo.
I'll try to see if there is a way to have CI bundle private deps before beaming at heroku
Usually when using capistrano, I will go and manually delete old releases from a deployed application. I understand that you can run cap deploy:cleanup but that still leaves 5 releases. Is this it's intended purpose? Is there another way to cleanup old releases to just 1 previous deploy?
You can use the :keep_releases variable to override the default of 5. Check this out.
You could do this automatically by setting this in your deploy.rb
set :keep_releases, 1
after "deploy:update", "deploy:cleanup"
In the past(I don't know exactly which version) this callback was the default, but later the developer decided to leave it to the user to decide. In capistrano 3 it was added back to the default deploy flow.
If you want to delete all releases except the last 3 for example you can run:
cap deploy:cleanup -s keep_releases=3
I had a similar problem. I wanted to keep the 5 releases for normal deployments but needed for certain situations to be able to remove all previous releases.
I was able to do this with a custom task. Create a file lib/capistrano/tasks/cleanup.rake and add the following code.
desc "Remove all but the last release"
task :cleanup_all do
set :keep_releases, 1
invoke "deploy:cleanup"
end
To run use bundle exec cap staging cleanup_all or cap staging cleanup_all