With Capistrano, how to rollback to a specific release?
My server's folder has a /release folder, how can I rollback to a specific one?
Is it possible for me to get a list of releases on my computer locally?
I'm using GIT and this didn't work:
cap deploy -s revision:HASH
Update
The answer was written in the times of capistrano version 2. With the current capistrano version 3 you can achieve the same by using
cap production deploy:rollback ROLLBACK_RELEASE=2010123
Please refer to the Capistrano documentation for further details.
Thanks to #codenoob for pointing this out!
Old version
The following should work:
cap deploy:rollback -s previous_release=/path/to/release/on/server
Example:
Lets say you have deployed your app to /srv/some_app and you have the following releases/directory structure:
|- srv
|- some_app
|- shared
|- current -> /srv/some_app/releases/2012123
|- releases
|- 2010123
|- 2011123
|- 2012123
If you now want to go back from the current (2012123) release to the 2010123 one, you would use
cap deploy:rollback -s previous_release=/srv/some_app/releases/2010123
Another option is
$ cap deploy:rollback ROLLBACK_RELEASE=20160614133327
from http://capistranorb.com/documentation/getting-started/rollbacks/#
Capistrano names the release directories by date/time.
From the capistrano shell, you can connect to all the machines you are deploying to, and examine them from there:
$ cap shell
# Show them - it might be a long list
cap> ls /mnt/html/deployed/releases/
** [out :: hostname.example.com] 20110521130031
# how many releases on each machine?
cap> ls /mnt/html/deployed/releases/ |wc -l
Related
I'm working on salt-stack for setting up multiple machines, I wanted to ask how can we deploy rpms(placed at a custom location in master) on to the minions? I already have an idea of how can we install packages using top.sls file and name of the package that needs to be installed on minions but what I'm looking for is to deploy my custom rpms on to the minions from master.
There are two ways to approach this:
Option 1:
Define the list of RPMs in a pillar file:
package_names:
- custom-rpm1: custom-rpm1-2.6.1-2.el7.x86_64.rpm
- custom-rpm2: custom-rpm2-release-el7-3.noarch.rpm
- custom-rpm3: custom-rpm3-latest.noarch.rpm
Then in an SLS file:
install-rpm:
pkg.installed:
- sources: {{ pillar['package_names'] }}
Option 2:
Copy the directory containing the RPMs (salt://rpms in below example is relative to file_roots) to target machine and use rpm command to install (with wildcard):
copy-rpms-dir:
file.recurse:
- name: /tmp/rpms
- source: salt://rpms
install-rpms:
cmd.run:
- name: rpm -ivh /tmp/rpms/*.rpm
- success_retcodes:
- 2
Installing with rpm command requires extra check for return codes as it returns non-zero (2) when RPM is already installed.
I was new to concourse, and set up the environment in my centos7.6 like below.
$ wget https://concourse-ci.org/docker-compose.yml
$ docker-compose up -d
Then login by `fly --target example login --team-name main --concourse-url http://192.168.77.140:8080/ -u test -p test`
I can see below.
[root#centostest ~]# fly targets
name url team expiry
example http://192.168.77.140:8080 main Sun, 16 Jun 2019 02:23:48 UTC
I used below yaml.xml named with 2.yaml
---
resources:
- name: my-git-repo
type: git
source:
uri: https://github.com/ruanbekker/concourse-test
branch: basic-helloworld
jobs:
- name: hello-world-job
public: true
plan:
- get: my-git-repo
- task: task_print-hello-world
file: my-git-repo/ci/task-hello-world.yml
Then I run below commands step by step.
fly -t example sp -c 2.yaml -p pipeline-01
fly -t example up -p pipeline-01
fly -t example tj -j pipeline-01/hello-world-job --watch
But i just hang on there , no useful response like below.
[root#centostest ~]# fly -t example tj -j pipeline-01/hello-world-job --watch
started pipeline-01/hello-world-job #3
Theoretically， it should print something like below.
Cloning into '/tmp/build/get'...
Fetching HEAD
292c84b change task name
initializing
running echo hello world
hello world
succeeded
Where I did wrong? thanks.
welcome to Concourse!
One thing that can be confusing when starting with Concourse is understanding when Concourse detects that the pipeline has changed and what happens if the pipeline is one file or multiple files.
Your pipeline (as the majority of real-world pipelines) is "nested": main pipeline file 2.yaml refers to a task file named my-git-repo/ci/task-hello-world.yml
What sets Concourse apart from other CI systems is that:
the main pipeline file (2.yaml) can reside everywhere, also in a different repository.
Due to 1, Concourse is unable to detect a change to the main pipeline file, you have to tell Concourse that the file has changed, either with fly set-pipeline or with automatic means such as the concourse-pipeline-resource.
So the following errors happen often:
Changing the main pipeline file, committing and pushing, and expecting Concourse to pick up the change. Missing: you have to do fly set-pipeline
Once doing fly set-pipeline becomes second nature, you can stumble upon the opposite error: Change both the main pipeline file and the nested task file, not pushing, doing set-pipeline. In this case, the only changes picked up by Concourse will be the ones to the main pipeline file, not to the task file. Missing: commit and push.
From the description of your problem, I have the feeling that it is a mixture of the gotchas I mentioned.
I followed the steps mentioned in the link
https://github.com/RTEMS/rtems-libbsd
for sparc and 4.12 version.
# cd /opt
# mkdir RTEMS
# cd RTEMS
# sandbox="$PWD/sandbox"
# mkdir sandbox
# cd "$sandbox"
# git clone git://git.rtems.org/rtems-source-builder.git
# git clone git://git.rtems.org/rtems.git
# git clone git://git.rtems.org/rtems-libbsd.git
Build and install the tools.
# cd rtems-source-builder/rtems
# ../source-builder/sb-set-builder --prefix="$sandbox/rtems-4.12" 4.12/rtems-sparc
Bootstrap the RTEMS sources:
-----------------------------
# cd "$sandbox"
# cd rtems
# PATH="$sandbox/rtems-4.12/bin:$PATH"
# ./bootstrap
# cd "$sandbox" or cd ..
# mkdir b-sis
# cd b-sis
# "$sandbox/rtems/configure" --target=sparc-rtems4.12 --prefix="$sandbox/rtems-4.12" --disable-networking --enable-tests=samples --enable-rtemsbsp=sis
# make
# make install
Build and install rtems-libbsd
================================
# cd "$sandbox"
# cd rtems-libbsd
# git submodule init
# git submodule update rtems_waf
# waf configure --prefix="$sandbox/rtems-4.12" --rtems-bsps=sparc/sis
In this step I got an error
Setting top to : /home/subhilash/RTEMS/sandbox/rtems-libbsd
Setting out to : /home/subhilash/RTEMS/sandbox/rtems-libbsd/build
No valid arch/bsps found
The error means waf configure was unable to find sparc/sis installed in your prefix. Probably, configure and make failed without an obvious error due to the removal of the sis BSP from RTEMS during the 4.12 development cycle. Try using erc32 instead of sis.
You may get timelier responses about RTEMS by inquiring on the users mailing list.
You should also be aware that the sis simulator for the erc32 does not have a simulated NIC. And as I right this, the greth driver that you probably want for LEON CPUs doesn't yet have a driver in the rtems-libbsd TCP/IP stack. It is supported by the legacy IPV4 stack.
We would welcome a contribution to port this driver to the new stack.
I don't know if the greth driver is supported by qemu but the basic leon3 is supported.
In Capistrano 2.x the DSL used to provide a variable/method release_name that would return the name of the directory into which the app was just deployed, e.g. 20140225134251, corresponding to .../releases/20140225134251.
I can't seem to find an equivalent for this in cap 3.
Also missing is current_revision, although I've replicated that with
`git rev-parse HEAD`.chomp
Did you try release_path and release_timestamp?
I've seen a lot of questions about pre 1.6 Magento installations to the most recent version (at the current moment 1.7.0.2) but there are a lot of answers that don't work for everybody.
So below the answer to the question:
How to upgrade Magento from a pre 1.6 installation to the most recent one.
There are a lot of versions and not all of them are working. This one has worked for me for a lot of versions, as far as 1.3 to 1.7.
Please add comments with solutions to problems you're experiencing, I can update the answer so other people get help from this topic too!
What you need:
- SUDO rights/root account on your server.
- The linux package 'nohub'
- make sure NOBODY can trigger the index.php. If your version supports maintenance.flag, put an empty maintenance.flag file in your Magento root.
Walkthrough
1) Download the latest Magento. Overwrite: ./download/* ./lib/* ./mage
2) Run these steps from you Magento root als SUDOer (if you're not root, put 'sudo' for all the commands)
find . -type f -exec chmod 644 {} \;
find . -type d -exec chmod 755 {} \;
chmod -R 777 ./var
chmod 550 mage
3) Go to your Magento root folder and type:
./mage list-upgrades
./mage config-set preferred_state stable
./mage upgrade-all --force
./mage install http://connect20.magentocommerce.com/community Mage_All_Latest --force
4) Now there is the last step. Note: In some situations this process can take up to 8+ hours!
nohup php -f ./index.php
Known issues
1) it's possible that your update gets in a loop. To find this loop, enable debugging.Edit: /lib/Varien/Db/Adapter/Pdo/Mysql.php (+/- line 112 and 112)
protected $_debug = true;
protected $_debuglogeverything = true;
This will write a debug to: /var/debug/[debug_file]
2) Read the file by opening the dir:
cd /var/debug/[debug_file] <-- replace with the actual filename
tail -f [debug_file]
3) If you use debug, the file will get HUGE! Make sure you delete it once in a while.
Tip: as a root user, type:
crontab -e
*/5 * * * * rm /[my_magento_base_folder]/var/debug/[debug_file] <-- add this line
If you want to read the file, add a # to this line and use tail to read it.
These steps help you find common errors and loops (if the tail shows a repeating error message)