cap deploy:rollback
I know this rolls back to the last revision. How can can I rollback to an older revision?
By executing cap deploy:rollback, you rollback to the previous release.
If you keep executing cap deploy:rollback, you will reach the release version you need.
It is not the perfect solution, but it works.
To rollback to a specific release
cap deploy:rollback -s previous_release=/path/to/desired_release
As far as I can tell, you can't rollback to a specific older revision, but you can deploy to a specific branch, revision or tag, etc.
For git:
cap -s branch=my_branch deploy
cap -s tag=my_tag deploy
For svn:
cap -s repository=http://blah.blah.blah deploy
cap -s revision=123 deploy
cap deploy:rollback:code will roll you back to the previously deployed version
Related
I have a small application running there using the heroku-buildpack-perl buildpack. It's just a small Plack application and it had been running fine for about two years.
But then, Heroku informed me that the stack it was running on was getting too old and I needed to upgrade it. "Just run a new deploy and the application will be installed to a new stack!" said they or something like that.
I inniciated a new deploy by creating an empty commit in the git repository, the deployment ran... but the application was crashing. From the logs I realised they updated the Perl version, but the deployment didn't update my XS libraries (I use local::lib, not sure if that's part of the buildpack or I set it up manually when creating the application back then).
In the end, I deleted the application and recreated it on the new stack, which worked OK. I don't keep any data anywhere so it was not a problem. What's the correct way to update the stack, though? There should be an option somewhere that tells Heroku to rebuild the dependencies, right?
Crossposted to PerlMonks.
Setting Heroku stack. In this case to heroku-20 equivalent with Ubuntu 20.04
$ heroku stack:set heroku-20
Since you are using a different stack, the old cache may not be compatible. Clearing cache:
$ heroku plugins:install heroku-builds
$ heroku builds:cache:purge -a appname
Triggering a rebuild:
$ git commit --allow-empty -m "Purge cache"
$ git push heroku master
Note:
You have to make sure that the buildpack you are using is compatible with heroku-20. If it is not it will not work. You will have to wait for the maintainer to update, use a different buildpack or fix the buildpack yourself and use that.
If you follow this step by step it is similar to deploying an entirely fresh app.
I am trying to install Cocoapods on a mac running MacOS Sierra. After writing "sudo gem install cocoapods" (getting no error), I entered "pod setup". However, my terminal just gets stuck on the line "Setting up CocoaPods master repo".
Can anyone help me identify my mistake? Thanks in advance!
Sometimes it can take long.
You could try running in verbose mode:
pod install --verbose
This'll show you what cocoapods is up to.
pod install or pod setup fetches whole repo with history when you first time run it.
If You don't need that commit history then.
pod setup
Ctrl +C
cd ~/.cocoapods/repos
git clone --depth 1 https://github.com/CocoaPods/Specs.git master
This is a general problem because how heavy cocoapod is. It's a popular library and have high amount of load to their sever.
So these are what I did to solve it:
1. pod setup
It will do "setting up master" again, DONT' WAIT, continue these steps below
2. Ctrl +C
3. pod repo remove master
4. cd ~/.cocoapods/repos
5. git clone --depth 1 https://github.com/CocoaPods/Specs.git master
It takes around 5 minutes for me (I think it depends on internet connection), then I can do "pod install".
https://stackoverflow.com/a/40541430/3258003
So, I'm new at tagging with svn and mvn.
Long story short, I reverted my project trunk back to a clean revision version (let's say "10") by running svn merge -r HEAD:10. The problem is, this was after I committed a bad tag (let's say "11").
I checked out code from the trunk to start anew ("10") and made small, test comments. But, when I ran a mvn clean install, the snapshot version that is being built the same version as revision "11" (let's say blah-1.11-SNAPSHOT).
I'm afraid that if I try to continue (mvn clean deploy then try to mvn release:prepare and -perform), the tag versions will get screwy - confused since there already is an "11" tag that exists - which I don't want to overwrite, necessarily.
What I ultimately want is to have this checked out version ("10") to build and deploy to the next tag version "12" (blah-1.12-SNAPSHOT).
Please help!
With capistrano v2 submodules can be includes in the deploy by using option:
set :git_enable_submodules, 1
In v3 this does not seem to work. Is this option still supported or is there a new way to reach the same goal?
In capistrano 3.1.x and later you can implement your own SCM strategy. There is an available gem that helps with git submodule, please see: https://github.com/i-ekho/capistrano-git-submodule-strategy.
NOTE: you may have problem with the repo folder if you already tried with the default git strategy. Simply go to the deploy directory on server and remove it and then run cap deploy again to fix.
The new Pull Request "828" is trying to implement that again:
https://github.com/capistrano/capistrano/pull/828
As discussed by #coffeeaddict, this Commit is a scrap of the code you will need to deploy locally until it's bundled with the capistrano itself. Please note that you need Capistrano >= 3.1.0 to use the code.
There is also another Gist that suggest to fix some issues of the strategy above.
It turns out it's very difficult to hook into any of the git tasks of capistrano (because they don't exist until the stage is set). Besides, git archive does not in any way provide support for submodules, so that part has to be completely replaced.
Copy and paste is also not an option for obvious reasons.
So I wrote this simple gem that can replace the git scm. It uses a similiar approach to capistrano 2, by cloning the repo with its submodules. It is very simple and enough for our goals. I suspect there are not many different usages of submodules out there (if people try to avoid complications).
https://github.com/juanibiapina/capistrano-scm-gitsubmodules
Let me know if it helps you too.
UPDATE:
This module has been deprecated with capistrano 3.1.0. Try this instead: https://gist.github.com/stevenscg/8176735
As you can see in the Capistrano source code https://github.com/capistrano/capistrano/blob/master/lib/capistrano/tasks/git.rake#L34 and https://github.com/capistrano/capistrano/blob/master/lib/capistrano/tasks/git.rake#L56 it uses git archive to check out the code into the release directory.
The code is reproduced here:
desc 'Clone the repo to the cache'
task clone: :'git:wrapper' do
on roles :all do
if test " [ -f #{repo_path}/HEAD ] "
info t(:mirror_exists, at: repo_path)
else
within deploy_path do
with git_environmental_variables do
execute :git, :clone, '--mirror', repo_url, repo_path
end
end
end
end
end
desc 'Update the repo mirror to reflect the origin state'
task update: :'git:clone' do
on roles :all do
within repo_path do
execute :git, :remote, :update
end
end
end
desc 'Copy repo to releases'
task create_release: :'git:update' do
on roles :all do
with git_environmental_variables do
within repo_path do
execute :mkdir, '-p', release_path
execute :git, :archive, fetch(:branch), '| tar -x -C', release_path
end
end
end
From that we can ascertain that submodules are not supported. As the commands to clone or initialize submodules are never issued, and git-archive ignores them.
The decision was made (source: Capistrano author here) not to include submodules "out of the box" as the hooks needed to build this in, if you need it are already there, and it's trivial to write an add-on task that does what you need to checkout/update submodules in a way that works for you. The Capistrano v2 submodule support often had unexpected consequences for people.
With that in mind. It might be worth to hooking into update, to initialize and update your submodules after the update is finished, and examining ways to augment git-archive do do what you need.
Each time I save an edit in Eclipse (GGTS/STS v3.4) it automatically runs the task: Computing Git status for repository [username].
The CPU usage rockets but it never seems to make any progress. I've left the process running for up to 15 minutes before giving up and stopping it manually. It then restarts the next time I save a change.
Presumably EGit is trying to synchronise but it isn't really clear what or why. Does anyone know why this might be happening and how to stop it?
Older versions of EGit used to automatically connect a project to its Git repository in case it finds a .git in any of the project's parent directories.
In your case, it seems you have a Git repository in your home directory. Depending on the size of your home directory, this can take a long time.
Since EGit 3.0.2, the home directory is no longer automatically indexed. So, make sure you are using EGit 3.0.2 or higher. In case you are using Eclipse 4.3.0, upgrade to 4.3.1. Otherwise upgrade to the newest version from the EGit download page.
After upgrading, open the Git Repositories view (using Ctrl+3 or Cmd+3 and typing its name). Then find the repository named [username] and remove it from the view.
In order to stop this thread from running, try:
rm -r .metadata/.plugins/org.eclipse.core.resources/.projects/*/org.eclipse.egit.core
and
rm -r .metadata/.plugins/org.eclipse.core.resources/.projects/*/.indexes/properties.index
seems to be working! credit to http://willtipton.com/coding/2014/09/21/Eclipse-building-git-something.html
Amir Dahan and Ryan Poolos's answer does work. Thanks a lot.
In Windows OS, you can open a "git bash" window if a git client was installed, then input the command.
If you just delete the "properties.index",they can be created again when you start the Eclipse next time.
cleaning up org.eclipse.egit.core and properties.index was useful. It works for me to get rid of computing Git status issue.
But now I cannot sync my project.