I have gone back to the original deploy.rb recipe and the problem is with
whatever capistrano is using for the scm password to log onto the git
host: I see this in the log files on that host:
Dec 3 14:45:21 inet09 unix_chkpwd[2813]: password check failed for user
(theheart)
Dec 3 14:45:23 i
On Monday, 2 December 2013 17:22:53 UTC-5, dbray wrote:
>
> That's a peculiar invocation, use a debugger to make sure :scm_password is
> set the way you think it is.
>
> Or try:
>
> set(:scm_password) {
> Capistrano::CLI.password_prompt("#{scm_user}@#{scm_server}
> password: ")}
>
> The for
This may have been overtaken by events. I have another somewhat related
question open at the moment respecting a logon issue with ssh inside
capistrano. Since the recipe is now running to that extent it may be that
whatever was causing this problem has been repaired or removed. It may be
tha
Problem: User logon fails when correct password entered.
I have verified that the password in use works via logging on in a terminal
session with the user id given below in the log. However, inputting this
password into the Capistrano-2.5.15 recipe using:
# You can bailout here with ^C ()
set(
On Friday, 29 November 2013 17:42:48 UTC-5, dbray wrote:
>
> Split is a string method not an Array method in 1.9.3 nor ruby 2.0
>
> How are you setting the branch to be deployed?
>
# Deploy this version. This is an SCM/VCS repository branch, not a tag.
set( :branch, "ForEx-Deploy-V.04.000.
Arch = i86_64
OS = CentOS-6.4 (RHEL6)
Ruby = v.2.0.0.p353
Rails = 4.0.1
Capistrano 2.15.5
We are trying to deploy a complex recipe which was last used this past
January and worked then without error. At that time we were using
Ruby-1.9.3 and RoR-3.2.8. We have updated our application to Ruby-2.
On Wednesday, January 2, 2013 12:49:52 PM UTC-5, Lee Hambley wrote:
>
> File.exists?() runs on your local machine. You'll need to test for remote
> files using bash script and the `test` program (man 1 test)
>
> - Lee Hambley
>
>
> Thanks.
--
* You received this message because you are subscr
I have this in my deploy.rb
run( %Q( echo $(ls -la /var/data/hll_th/etc/hll_th.d/database.yml) ) )
puts( File.exists?( "/var/data/hll_th/etc/hll_th.d/database.yml" ).to_s )
Running that task gives this result:
** [out :: inet01.hamilton.harte-lyne.ca] -rw-r--r-- 1 theheart theheart 0
Jan 2 1
y:update_code] exception while rolling back:
Capistrano::ConnectionError, connection failed for: theheart.harte-
lyne.ca (Errno::ECONNREFUSED: Connection refused - connect(2))
/home/byrnejb/.rvm/gems/ruby-1.8.7-p302/gems/capistrano-2.5.19/lib/
capistrano/recipes/deploy/scm/git.rb:231:in `query_revision&
Joshua Kolden wrote:
> I just did this last night. What I did to accomplish this was to tag
> the version in my git repository, after finding the appropriate
> revision like so:
>
> git tab release3 2dd...28e4
>
> Then I made a branch with the same name as the tag like so:
>
> git co -b release
byrnejb wrote:
>
> Just as a WAG, try this in your deploy.rb settings:
>
> # Need this because ssh requires a pty by default
> default_run_options[:pty] = true
It also occurs to me that your server may need to have the github
host's public key added to its list of known
rmossuk wrote:
> hi all
>
> i am having a problem with deploying my application to my server.
>
>
> when i run cap deploy:cold it asks me for my passphrase to connect to
> github repo then it asks it again to connect to my server but then it
> gives me an error permission denied (public key) an
On Jul 20, 5:32 pm, Lee Hambley wrote:
> Caleb,
> That comment shouldn't be there - I will check, but I think it came from a
> problem release in 2.5.7.
>
> You can safely use the restart commands as you always have done, without
> commenting-in either of those lines. In fact you can safely rem
13 matches
Mail list logo