I updated to Cap 3 and it appears that set :deploy_via, :copy is no longer supported. In the release annoucement there is a link to a video for replicating the copy strategy which currently returns a 404.
I used the :copy strategy because the server did not have access to git or access to the repository because it was behind a firewall.
What is the best way to replicate this functionality with v3?
I ran into the same issue and posted a similar question on the capistrano google group.
See here: https://groups.google.com/forum/#!topic/capistrano/BRa4Vj1_mEo
Short answer: Write your own rake task.
The capistrano maintainer provided some example code, via a blog post on his website, that can be found here: http://lee.hambley.name/2013/06/11/using-capistrano-v3-with-chef.html
In the end, we've decided to go w/ a different strategy entirely, and implement a mirror repository on the same network as our servers.
There is one work in the exact same way
https://github.com/xuwupeng2000/capsitrano-scm-gitcopy
Capistrano 3 :copy
A copy strategy for Capistrano 3, which mimics the :copy scm of Capistrano 2.
This Gem is inspired by and based on https://github.com/wercker/capistrano-scm-copy.
Thank wercker so much.
This will make Capistrano tar the a specific git branch, upload it to the server(s) and then extract it in the release directory.
Usage
cap uat deploy -s branch=(your release branch)
You can use its gem - https://github.com/WildZero/capistrano-scm-tar-copy
set:
set :scm, :copy
set :include_dir, '/User/w1ldzer0/ExampleDir'
and go
Related
We are running a local Artifactory Pro installation and have rubygems.org configured as a Remote Repository.
When running bundle install in a CI Job, the local Artifactory Instance does return a 404 File not found when querying for the /versions file. When doing a manual lookup in the Remote (&Cache) Repo, the file >is present<.
The path we pass to bundle install is provided by the Set me up Wizard and looks like this:
https://$rtf-instance.com/artifactory/api/gems/gems-remote/versions
This was mentioned in an issue here: https://www.jfrog.com/jira/browse/RTFACT-16005
and should have been fixed, but it is still not working in our installation.
Can't find any mention of RTFACT-16005 or the related RTFACT-19012 in the Release Notes.
Repo is setup with default values, no additional config done.
Are we missing something?
Environment:
debian 10 (buster)
nginx 1.14.2
artifactory-pro 7.15.4 / 7.15.3
To enable the gems compact index support you need to add the following system property (under $JFROG_HOME/var/etc/artifactory/artifactory.system.properties):
artifactory.gems.compact.index.enabled=true
You will need to restart Artifactory afterward.
This can be found in JFrog Wiki, here: https://www.jfrog.com/confluence/display/JFROG/RubyGems+Repositories#RubyGemsRepositories-RetrievingLatestRubyGemsPackageCompatiblewithYourRubyVersions
I have a Jekyll site that uses the jekyll-paginate plugin and is hosted by GitHub Pages, pretty standard.
Does anybody know of other solutions to handle pagination such that I could build two blogs from the same site at domain/blog1 and domain/blog2 using this solution, but also retain pagination?
Retaining the current pagination design is not a priority. Creative ideas that require redesign are welcome.
I know jekyll-paginate-multiple exists, but GitHub Pages does not support it natively, and I would have to maintain two repos to maintain the site code and build artifacts separately, which is not ideal.
Use any custom Plugin/Gem with your GitHub Pages hosted Jekyll blog
Here is how you CAN use any custom plugin on a GitHub Pages hosted website. I use this on my own blog so I'm 100% certain that it works. The basic idea is that you use TravisCI to build your custom Jekyll site on a staging branch and then push it automatically to your GitHubPages master branch that serves your website. Here comes the quick walkthrough:
a) you configure GitHub Pages to host from the docs folder of your master branch
b) you add and configure a staging branch to be the default branch of your repo, there is where you do all your local work, releases work through setting a git tag on this branch
c) you use _config.yml file to set your destination directory to docs
# _config.yml
destination: docs
d) to avoid build issues with Travis CI you can add Gemfile.lock to your .gitignore file and the docs folder to your local .git/info/exclude since you don't want to push them anymore. To exclude the docs folder from a local push is optional, but for me that works best. You also may need to delete the Gemfile.lock first and then let Travis CI pick the fitting versions for the selected Docker OS, otherwise you can run into version conflicts which can be pretty hard to fix.
e) to deploy with Travis CI into production a.k.a. your live site you add a .travis.yml file alike :
language: ruby
rvm:
- 2.6.3
install:
- bundle install
script:
- JEKYLL_ENV="production" bundle exec jekyll build
deploy:
provider: script
script: bash script/deploy.sh
skip_cleanup: true
on:
tags: true
branch: staging
branches:
only:
- staging
- /\d+\.\d+(\.\d+)?(-\S*)?$/
env:
global:
- NOKOGIRI_USE_SYSTEM_LIBRARIES=true
- secure: TRAVIS_SECRET_KEY_FOR_GITHUB_CREDENTIALS
sudo: false
cache: bundler
notifications:
email: false
g) script/deploy.sh looks somewhat like this:
#!/usr/bin/env bash
bundle install
JEKYLL_ENV="production" bundle exec jekyll build
git status
git add .
git commit -m"[skip travis] Automated build"
git remote set-url origin https://USERNAME:$PSW#github.com/YOUR_GIT_USER/YOUR_REPO.git
git push origin HEAD:master --force
e) to get your encrypted TRAVIS_SECRET_KEY_FOR_GITHUB_CREDENTIALS in .travis.yml with the used $PSW variable used in the deploy script, just follow the Encryption Key Doc
Once this configuration is done, you can use any Gem the same way as on localhost since the building part is not done by GitHub anymore but TravisCI.
Conclusion
You just work on staging and only let Travis CI push to your master branch. You use tags in the form 1.0.0 to deploy. All you need to do now is to add jekyll-paginate-multiple to your Gemfile and _config.yml and you are ready.
If anyone is interested in more details for those step, have a look at this Blog Post detailing the issue
If jekyll-paginate-multiple works in your context, you can use it on GitHub pages as well.
All you need to do is to copy
https://github.com/scandio/jekyll-paginate-multiple/blob/master/lib/jekyll-paginate-multiple.rb
into your repos _plugins folder and you are good to go.
My heroku slug size is 389mb, so push is rejected. Now the Point is, if i deploy my same application on new domain (by using heroku create again), the slug size, i am seeing is just 200mb.. Why its different? Then I have tried this approach:
Approach 1: by deleting .git folder from my project directory, then again git init. and then deploying again on same heroku app.. It didn't make any differences!
Approach 2: By declaring .slugignore file in root of project folder. But its too not making any diff!
Approach 3: as per this site, https://github.com/heroku/heroku-repo
I have reset my repo like this,
heroku repo:reset -a appname
But, nothing happened!! What to do now? Can u guide me? Thnx.
As Heroku suggests:
Inspect your slug with heroku run bash and by using commands such as ls and du
Move large assets like PDFs or audio files to asset storage
Remove unneeded dependencies and exclude unnecessary files via .slugignore
Hey I was able to find the solution. Here is what i have done:
I have downloed Heroku Repo plugin from this site :https://github.com/heroku/heroku-repo just by this line:
heroku plugins:install https://github.com/heroku/heroku-repo.git
then I have just rebuilt my app by this command:
heroku repo:rebuild -a appname
This will empty the remote repository and push the repository up again, effectively triggering an app rebuild. and I got whole working app with original downsized (207mb) again. that's it.
I have a simple deployment via capistrano from a Git repository. At first I was deploying form GitHub, everything worked just fine. But then I moved my repository to BitBucket and now I'm getting
fatal: Could not parse object '9cfb...'.
The problem goes away once I change
set :deploy_via, :remote_cache
to
set :deploy_via, :copy
but that doesn't fix the problem, it only bypasses it. Is there any way I can tell capistrano to just drop the old cache?
Capistrano 2.X
Delete and re-clone the repo using the new address:
cd $deploy_to/shared
rm -rf cached-copy
git clone ssh://git#example.org/new/repo.git cached-copy
Modify your config/deploy.rb to use the new repo:
set :repository, "ssh://git#example.org/new/repo.git"
set :scm, :git
set :deploy_via, :remote_cache
Deploy again:
cap deploy
Capistrano 3.X
Remove the $deploy_to/repo directory
Modify your config/deploy.rb (same as 2.X)
cap deploy
I gotta say I’m not sure, since I haven’t been able to test this but this should work:
cap deploy:cleanup -s keep_releases=0
Since it wipes every release (cache) from the server.
Apparently you will also need to remove shared/cached-copy, because this doesn’t seem to be cleaned by the Capistrano call above according to the comment below.
Capistrano 2 and below
SSH to your server and update the repo in ./shared/cached-copy/.git/config of the deployment folder, or just remove the ./shared/cached-copy
Capistrano 3 and above
SSH to your server and update the repo in ./repo/config of the deployment folder.
Check Fixing Capistrano 3 deployments after a repository change
I solved this with the following in deploy.rb:
namespace :deploy do
task :cope_with_git_repo_relocation do
run "if [ -d #{shared_path}/cached-copy ]; then cd #{shared_path}/cached-copy && git remote set-url origin #{repository}; else true; fi"
end
end
before "deploy:update_code", "deploy:cope_with_git_repo_relocation"
It makes deploys a little slower, so it's worth removing once you're comfortable that all your deploy targets have caught up.
You need to change git origin in your /shared/cached-copy folder
cd /var/www/your-project/production/shared/cached-copy
git remote remove origin
git remote add origin git#bitbucket.org:/origin.git
try cap production deploy
The most simple way is just changing the repo url to the new one in .git/config in the shared/cached-copy directory on the webserver. Then you can do a normal deploy as usual.
Depends on your version Capistrano 3 is different from it's older ancestors:
Read my original answer here and how to fix similar issues Capistrano error when change repository using git
If you need to do a lot of repo's you might want to add a task for it.
For capistrano 3 you add this task in your deploy.rb
desc "remove remote git cache repository"
task :remove_git_cache_repo do
on roles(:all) do
execute "cd #{fetch(:deploy_to)} && rm -Rf repo"
end
end
And then run it once for every stage:
cap testing remove_git_cache_repo
Here's the Capistrano 3 version of what this answer talks about. It might be tedious to do what the answer suggests on each server.
So drop this in deploy.rb and then run cap <environment> deploy:fix_repo_origin
namespace :deploy do
desc 'Fix repo origin, for use when changing git repo URLs'
task :fix_repo_origin do
on roles(:web) do
within repo_path do
execute(:git, "remote set-url origin #{repo_url}")
end
end
end
end
For Capistrano 3.0+
Change the repository URL in your config/deploy.rb
Change the repository URL in the your_project/repo/config file on the server.
I'm using Heroku to host a Rails app, which means using Git to deploy to Heroku. Because of the "pure Git workflow" on Heroku, anything that needs to go upstream to the server has to be configured identically on my local box.
However I need to have certain configuration files be different depending on whether I'm in the local setup or deployed on Heroku. Again, because of the deployment method Heroku uses I can't use .gitignore and a template (as I have seen suggested many times, and have used in other projects).
What I need is for git to somehow track changes on a file, but selectively tell git not to override certain files when pulling from a particular repo -- basically to make certain changes one-way only.
Can this be done? I'd appreciate any suggestions!
You can have config vars persistently stored ON each heroku app's local setup so they do not have to be in your code at all! so the same code can run on multiple heroku sites but with different configuration. It very simple, easy, elegant...
It's the approach we used. (We used it for the SAME thing... we have multiple clones of the SAME app at Heroku, but we want only ONE source at github, in our dev local directory we do the PUSH to ORIGIN (github), then when we have it the way we like it, we CD to the prod local directory, which goes to the SAME github repository, and we ONLY PULL from GITHUB into this directory, never push (eg, all pushes to github come from our dev directory, the prod directory is just a staging area for the other heroku app.)
By having the different configs ON the different HEROKU sites (as explained below), the EXACT SAME CODE works on BOTH heroku sites.
So our workflow is: (the key is that BOTH directories point to SAME github repo)
cd myDEVdir
*....develop away....*
git add .
git commit -am "another day, another push"
git push origin *(to our SINGLE github repo)*
git push heroku *(test it out on heroku #1)*
cd ../myPRODdir
git pull *(grabs SAME code as used on other site *)
git push heroku *(now the SAME code runs on Heroku #2)*
that's it!
Now here's how you keep your site-specific config vars ON the heroku site:
http://docs.heroku.com/config-vars
on your local command line, for EACH of your two local directories, do:
$ heroku config:add FIRST_CONFIGVAR=fooheroku1
Adding config vars:
FIRST_CONFIGVAR => fooheroku1
$ heroku config:add SECOND_CONFIGVAR=barheroku1
Adding config vars:
SECOND_CONFIGVAR => barheroku1
to see the ones you have defined:
$ heroku config
FIRST_CONFIGVAR => fooheroku1
SECOND_CONFIGVAR => barheroku1
then cd to your other directory myPRODdir and do the SAME thing, only set the same remote heroku vars to fooheroku2 and barheroku2.
then in your rails app you simple refer to them like so:
a = ENV['FIRST_CONFIGVAR']
One app will read 'fooheroku1' the other app will read 'fooheroku2'
And finally, on your LOCAL directory myDEVdir, where you run in DEV mode, put the same config commands in your config/environment/development.rb file your 'dev' version of the config vars will be set to whatever they should be:
ENV['FIRST_CONFIGVAR'] = "foodev"
ENV['SECOND_CONFIGVAR'] = "bardev"
Easy, elegant. Thanks, Heroku!
Here are a few solutions:
1) If you want to ignore files only on heroku, use slugignore
2) If your changes are minor, stay DRY and use universal config files, inserting switches for server-specific behavior
if Rails.env == "production"
#production server code
elsif Rails.env == "development"
#development server code
else
#test server code
end
3) If your changes are major, write one config file and add a "smudge file" to config/initializers for each additional server. Basically, you would have separate files using the technique in (2).
4) If your changes are SWEEPING (unlikely), then maintain separate branches for each server.
5) This script can do exactly what you requested, but may be overkill.
I hope that helped.