Hi this is the error that is appearing when I'm deploying using Capistrano 3 with a Rails 4 app to a Webfaction server.
The deploy has failed with an error: #<SSHKit::Command::Failed: cd
/home/username/webapps/app/repo && git rev-parse --short HEAD stdout: Nothing written
cd /home/username/webapps/app/repo && git rev-parse --short HEAD stderr: Nothing written>
My git repository is inside webfaction, I created it as --bare repository, don't know if that changes things. I set it up the URL like this in my capistrano file:
set :repo_url, '/home/username/webapps/git_app/repos/myrepo.git'
Any additional info that you may need, please ask
Thanks.
I just worked around this issue with this procedure, I don't believe it's the correct one but it helped me through:
I copied all the files (the git config files) from my repo: /home/username/webapps/git_app/repos/my_git.git/
to the mirror repo that Capistrano builds in Webfaction: /home/username/webapps/git_app/repo
Like this:
cp -a /home/username/webapps/git_app/repos/my_git.git/. /home/username/webapps/git_app/repo
Related
Got several Jenkins job. But when ever we run them, we get stuck for 15-20 minutes at following:
Modules changed, recalculating dependency graph
Following is the complete log:
In progress
Console Output
Started by user *****
Building remotely on ****server in workspace *****workspace
git rev-parse --is-inside-work-tree
Fetching changes from the remote Git repository
git config remote.origin.url *****
Fetching upstream changes from *****
git --version
using GIT_SSH to set credentials *****
git fetch --tags --progress **** +refs/heads/:refs/remotes/origin/
git rev-parse origin/*^{commit}
Checking out Revision ** (origin/****)
git config core.sparsecheckout
git checkout -f *****
First time build. Skipping changelog.
[*****] $ /bin/bash -xe /tmp/hudson*.sh
+ rm -rf .repository/com/****
Parsing POMs
using settings config with name **** Settings
Downloaded artifact ******.pom
Downloaded artifact ******.pom
Modules changed, recalculating dependency graph
My question is how to remove or shorten this wait time during dependency graph calculation.
At the moment I'm troubling with Travis-CI Pro and a private submodule.
This is some travis.yml code I've found, the $GIT_USER and $GIT_TOKEN envs are set in travis settings.
git:
submodules: false
before_install:
- sed -i 's/git#github.com:/https:\/\/$GIT_USER:$GIT_TOKEN#github.com\//' .gitmodules
- git submodule update --init --recursive
During the build process I get the following error:
$ sed -i 's/git#github.com:/https:\/\/$GIT_USER:$GIT_TOKEN#github.com\//' .gitmodules
0.67s$ git submodule update --init --recursive
Submodule 'ro-realm' (https://github.com/[secure]/ro-realm.git) registered for path 'ro-realm'
Cloning into '/home/travis/build/[secure]/ro-order-worker/ro-realm'...
remote: Invalid username or password.
fatal: Authentication failed for 'https://github.com/[secure]/ro-realm.git/'
Thanks for your help.
I wouldn't call this a recommended solution, but how about this to fix the issue?
# Generate from github, confirm that user and token are correct
echo https://${GIT_USER}:${GIT_TOKEN}#github.com/chaconinc/DbConnector
git submodule add https://${GIT_USER}:${GIT_TOKEN}#github.com/chaconinc/DbConnector
git submodule update --init --recursive
On the install step, Travis CI clones the repo, which looks similar to this:
git clone --depth=50 --branch=master https://github.com/user/repo.git user/repo
How can I customize / override this?
Background: I am using tag based deploys. The way Travis checks out tagged builds (--branch=<tagname>), the git repository is in a detached state without access to branches. However, for deployment I need to know on which branch I am. My solution is to do a "normal" clone and then switch to the tagged commit.
You can clone the repository again in the install step. That way you clone the repository twice, but it seems to work.
# .travis.yml
install:
- git clone https://github.com/$TRAVIS_REPO_SLUG.git $TRAVIS_REPO_SLUG
- cd $TRAVIS_REPO_SLUG
- git checkout -qf $TRAVIS_COMMIT
Per the Travis docs you can add the following to your .travis.yml to remove the --depth flag:
git:
depth: false
As --depth implies --single-branch, removing this flag means that all branches will be checked out, which isn't the default behaviour.
I found that in order to get access to your whole repo you need the following:
install:
- git config remote.origin.fetch +refs/heads/*:refs/remotes/origin/*
- git fetch --unshallow --tags
This way you'll have access to remote branches and tags (e.g. can do checkout).
If you're on a tag but no longer want to be in a detached HEAD state you can create a new branch that points to the tag (according to this discussion):
install:
- git config remote.origin.fetch +refs/heads/*:refs/remotes/origin/*
- git fetch --unshallow --tags
- git symbolic-ref --short HEAD || git checkout -b ${TRAVIS_BRANCH}-test $TRAVIS_BRANCH
Note: git symbolic-ref --short HEAD will fail if you're in a detached HEAD state.
The problem is not really that you are in a detached branch. It is that git does not allow you to fetch the tags: git fetch --tags will only fetch the branch spcified by --branch in the git clone command you gave.
I explain this in more details this answer.
To solve you issue (checking out a specific tag) you can call a script that looks like this, after the repo is cloned:
# Keep track of where Travis put us.
# We are on a detached head, and we need to be able to go back to it.
build_head=$(git rev-parse HEAD)
# fetch the tags
git config --replace-all remote.origin.fetch +refs/heads/*:refs/remotes/origin/*
git fetch --tags
# checkout the tagged commit
git checkout -qf <your tag>
# now do your stuff
# go back to where we were at the beginning
git checkout ${build_head}
Run this during your build to have access to origin tags / branches
git config remote.origin.fetch "+refs/heads/*:refs/remotes/origin/*" 1>/dev/null
git fetch origin -q
After that you can run this command to find branches containing your commit
BRANCHES=`git branch -a --contains "$TRAVIS_TAG"`
I've created a script a loooong time ago to fetch the 'environment' branch where the tag was created for continuous deployment purpose.
It may inspire you: https://gist.github.com/rolebi/a0eb1f783b7f3a5f21a631c8da1582dc
Use it like that:
TARGET_ENV="`test $TRAVIS_TAG && bash scripts/get_branch_for_git_reference.sh $TRAVIS_TAG`"
Disable git clone and then clone the repository again in the install step. The repository will be cloned only once in this way. In this "normal" clone you will able to do what ever you want.
git:
clone: false
install:
- git clone https://github.com/$TRAVIS_REPO_SLUG.git $TRAVIS_REPO_SLUG
- cd $TRAVIS_REPO_SLUG
Or you could just query the remote. Add the following to .travis.yml:
env:
global:
# get all the branches referencing this commit
- REAL_BRANCH=$(git ls-remote origin | sed -n "\|$TRAVIS_COMMIT\s\+refs/heads/|{s///p}")
# or check if we are on a particular branch:
- IS_RELEASE=$(git ls-remote origin | grep "$TRAVIS_COMMIT\s\+refs/heads/release$"
(I am surprised that the git gurus hadn’t come up with this one already)
You can convert the already existing shallow clone to a full clone. To do so execute git fetch --unshallow (available since git version 1.8.3) during the install step.
# .travis.yml
install:
- git fetch --unshallow --tags
The --tags flag forces to fetch all tags even if they don't belong to the checked out branch. This is needed if your build also depends on tags from other branches.
Solutions
When configing the branchs to build remove the wildcard *:
*/master to be only master
This error only occours when a GIT SCM is related to the JOB.
Ex: I have a daily job to build an Android project.
First i thought that it was a cron problem, currently im using 50 10 * * *, but i have tried H 10 * * * without any success. When the time comes, it always build the job (Failure or Success) and it queue another job.. and so on...
Would last have run at Friday, May 22, 2015 10:01:58 AM BRT; would next run at Saturday, May 23, 2015 10:01:58 AM BRT.
Even a build with parameter it queue a another job everytime.
So it stays in a build loop, forever..
Config:
Jenkins ver. 1.614.
Ubuntu 14.04.2 LTS (GNU/Linux 3.13.0-46-generic x86_64)
GIT client plugin: 1.17.1
GIT plugin: 2.3.5
Console Output:
Started by an SCM change
Building in workspace .../jobs/PROJECT_NAME/workspace
> git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
> git config remote.origin.url ssh://GIT_ADDRESS/ # timeout=10
Cleaning workspace
> git rev-parse --verify HEAD # timeout=10
Resetting working tree
> git reset --hard # timeout=10
> git clean -fdx # timeout=10
Fetching upstream changes from ssh://GIT_ADDRESS/
> git --version # timeout=10
> git -c core.askpass=true fetch --tags --progress ssh://GIT_ADDRESS/ +refs/heads/master:refs/remotes/origin/master
> git rev-parse refs/remotes/origin/master^{commit} # timeout=10
> git rev-parse refs/remotes/origin/origin/master^{commit} # timeout=10
Multiple candidate revisions
Scheduling another build to catch up with PROJECT_NAME
Checking out Revision e6d726c2d31cb0d7e6fad4362ee85e6fac1712c6 (refs/remotes/origin/master)
> git config core.sparsecheckout # timeout=10
> git checkout -f e6d726c2d31cb0d7e6fad4362ee85e6fac1712c6
> git rev-list e6d726c2d31cb0d7e6fad4362ee85e6fac1712c6 # timeout=10
[Gradle] - Launching build.
[android] $ gradle clean build assemble
...
Maybe the problem is this?
> git rev-parse refs/remotes/origin/master^{commit} # timeout=10
> git rev-parse refs/remotes/origin/origin/master^{commit} # timeout=10
Multiple candidate revisions
Scheduling another build to catch up with PROJECT_NAME
The build loop:
Job Config:
Global Config:
Review the beginning of the console logs, for both the job that you manually started, and the job that gets queued next automatically.
In the beginning of the console log, it gives a reason for why the build was triggered, for example 09:46:05 Started by an SCM change or 16:06:58 Started by user Slav. Please add to the question the start of both console logs.
Edit:
Now that we know that Jenkins detects an SCM change trigger we can further speculate that what's causing this behaviour is an SCM post-commit hook of some sort, or another script activation sending a request to Jenkins.
Post-commit hooks should not work if SCM polling is not enabled, but nothing else makes sense, so let's investigate that avenue. Add /pollingLog/ to the build URL of the build number that was triggered "by SCM change". There is a chance that nothing would be found, but if there is, but let's make sure.
Next, if possible, bind Jenkins to a different IP address and/or port. If there are "rogue" scripts that are triggering secondary builds, they won't be able to adapt to changed address.
Edit 2:
Looks like there is a bug in git client plugin itself, it was fixed in version 1.6.2. Please check the version of your git plugins.
Sources: https://issues.jenkins-ci.org/browse/JENKINS-10767 and https://issues.jenkins-ci.org/browse/JENKINS-20286
Above screen shot looks fine but i am sure there must be some other configuration.
can you provide detail (rest of the) configuration too?
Please give below code in Build periodically section and try if that resolves the issue
H(0-50) 10 * * *
Make sure your repo doesn't have more than one branch that matches your Branch Specifier by using the full path to the branch: "refs/heads/master" instead of "*/master"
When I run 'cap production deploy' is am not getting my latest master on the server. Here are so lines from the deploy log:
DEBUG[208486a4] Command: ( GIT_ASKPASS=/bin/echo GIT_SSH=/tmp/----/git-ssh.sh /usr/bin/env git ls-remote git#github.com:------.git )
DEBUG[208486a4] 3983b992ede90e5957dc9ddb953c4df488354d7d HEAD
DEBUG[208486a4] 3983b992ede90e5957dc9ddb953c4df488354d7d refs/heads/master
DEBUG[208486a4] Finished in 0.832 seconds with exit status 0 (successful).
Then later on in the log:
INFO[38bea0b3] Running /usr/bin/env echo "Branch master (at 18306db) deployed as release 20140626124746 by dean; " >> /home/deploy/royalty/revisions.log on 96.126.121.168
DEBUG[38bea0b3] Command: echo "Branch master (at 18306db) deployed as release 20140626124746 by dean; " >> /home/deploy/royalty/revisions.log
INFO[38bea0b3] Finished in 0.116 seconds with exit status 0 (successful).
I have recently switched from using a repo at assembla to github. The commit: 18306db was the last commit that I pushed up to assembla. But all the new commits after that show up when I view the repo on github.
I changed the origin url with set-url and then pushed the up to github.
What am I missing here?? Thanks
Finally found a question that was related here: Capistrano error tar: This does not look like a tar archive
And followed the advice in the second answer which worked for me.
Logged into server and deleted the app_name/repo folder (rm -rf /app_name/repo )