When debugging it's useful to have which shell commands were run to figure out what exactly was failing. Jenkins does this by default, which is super nice.

I have code for this, let me know if you think it's a good idea and I can PR it.

@dblandin We broke shit in #96. Any idea what should be there?

undefined local variable or method `lock_params' for #<Receiver:0x007f25230dd500>
/app/app/receivers/receiver.rb:42:in `run_deployment!'
/app/app/receivers/receiver.rb:54:in `run!'
/app/app/receivers/receiver.rb:16:in `perform'

I am not able to authenticate heaven with my personal token. I have all env vars correctly set but when I visit /resque I get

GET https://api.github.com/teams/696075/members/raja: 401 - Bad credentials // See: https://developer.github.com/v3

When I'm deploying app to heroku, using Deploy button from the Installation page, i'm getting this after hitting Deploy For Free button.

Configure Environment
App environment configuration failed. This can mean your app.json's project is not a valid Heroku application. Please ensure your app is deployable to Heroku and try again.

I've filled in:

• GITHUB_TOKEN
• GITHUB_CLIENT_ID
• GITHUB_CLIENT_SECRET
• GITHUB_TEAM_ID
• and left HEROKU_API_KEY empty

any idea, why it could happen?

We recently enabled Status webhook events to let Heaven handle auto-deployment of passing master builds but we've encountered some odd behavior and had to disable it pretty quickly. First, it seems like multiple deployments are triggered.

Here's a screenshot of my notification output after merging a PR containing just 1 commit:

I'm not too familiar with the intent behind the Deployment.latest_for_name_with_owner class method but a deployment seems to trigger for each result returned.

We're deploying 3 apps trough heaven currently.

Here are some counts from Deployment.latest_for_name_with_owner:

> Deployment.latest_for_name_with_owner('dscout/dscout').count
=> 4
> Deployment.latest_for_name_with_owner('dscout/dscout-web').count
=> 5
> Deployment.latest_for_name_with_owner('dscout/dscout-efflux').count
=> 6

Are multiple results expected?

Hi All,

We started to implement heaven here... We'd like to have heaven hosted on heroku but in order to deploy to our servers we need to use a ProxyCommand to hop from a jumpbox. We are using the bundler_capistrano provider for our production boxes.

I am currently stuck trying to figure out how ssh-agents should be handled. How would you all recommend handling this? This is currently where I am having trouble:

DEBUG [85870980] Running /usr/bin/env git ls-remote [email protected]:doximity/residency_navigator.git as [email protected]
DEBUG [85870980] Command: ( RBENV_ROOT=/usr/local/rbenv RBENV_VERSION=2.2.2 GIT_ASKPASS=/bin/echo GIT_SSH=/tmp/residency/git-ssh.sh /usr/bin/env git ls-remote [email protected]:doximity/residency_navigator.git )
DEBUG [a637ae9f] Running /usr/bin/env git ls-remote [email protected]:doximity/residency_navigator.git as [email protected]
DEBUG [a637ae9f] Command: ( RBENV_ROOT=/usr/local/rbenv RBENV_VERSION=2.2.2 GIT_ASKPASS=/bin/echo GIT_SSH=/tmp/residency/git-ssh.sh /usr/bin/env git ls-remote [email protected]:doximity/residency_navigator.git )
DEBUG [85870980] Error reading response length from authentication socket.
DEBUG [a637ae9f] Error reading response length from authentication socket.
DEBUG [85870980] Permission denied (publickey).
DEBUG [85870980] fatal: Could not read from remote repository.
DEBUG [85870980]
DEBUG [85870980] Please make sure you have the correct access rights
DEBUG [85870980] and the repository exists.
DEBUG [85870980] Finished in 0.818 seconds with exit status 128 (failed).

The above fails out due to there being no ssh-agent present...

I'm trying to sort out what each of the various tokens and keys set in the environment variables are for. This is my understanding. Please correct where I'm wrong.

GITHUB_CLIENT_ID and GITHUB_CLIENT_SECRET
Used only to limit access to the Resque dashboard.
Generate a new one under Developer Applications at https://github.com/settings/applications. I'm unclear what to enter for the callback URL.
Required if you want to view the Resque dashboard. Optional otherwise.

GITHUB_TEAM_ID
ID of the GitHub organization team to which you want to limit access to the Resque dashboard.
Required if you want to view the Resque dashboard and limit access to a specific GitHub organization team. Optional otherwise.

GITHUB_DEPLOY_TOKEN
Used to authorize access to clone a GitHub repository when deploying an application. Applies to your personal user, not any organization or team. This user must have pull access to the repository you want to clone.
Generate a new one under Personal access tokens at https://github.com/settings/applications.
Required

HEROKU_DEPLOY_PRIVATE_KEY
Private SSH key that is allowed to push to the application you want to deploy via Heaven. Add the corresponding public SSH key at https://dashboard.heroku.com/account.
Required

RAILS_SECRET_KEY_BASE
Required by Rails. Instructions in the README

In the document: https://github.com/atmos/heaven/blob/master/doc/providers.md
It says we should use https:// instead of git:// for repo url. However, in such case, git will ask for the username & password, which obviously will break the deployment .. How can I resolve this?

e.g: we use a campfire gem inside our cap tasks (to do deploy notifications), so our deploys fail like this:

`require': cannot load such file -- sparks 

I guess the right thing to do here would be to check for the existence of a Gemfile in the checked out repo, then run bundle install before running the capistrano task? I am happy whipping up a PR, just wanna check that approach sounds sane to you.

I am encountering a problem that I am not able to deploy my private project on github if the server I am deploying to do not have the access to the repo.

Say I have a private repo https://github.com/myname/project . I create a deployment event, then github notify heaven which already has my ssh private key that can access to the private repo and also the server I want to deploy to. Then heaven execute command like this fab -R staging deploy:branch_name=master.

My fabfile.py is something like this:

from fabric.api import env
from fabric.context_managers import cd
from fabric.operations import run

env.shell = '/bin/bash -l -c'
env.user = 'username'
env.roledefs.update({
    'staging': ['staging.mydomain.com']
})

def deploy(branch_name):
        # pull project from github, BUT ACCESS DENIED
        run('git clone -b %s --single-branch [email protected]:myname/project.git .' % branch_name)
        # Do something after pulling the project from github

So my question is, how can deploy like this, without the need to generate ssh keys in every single deploy server and then add those keys to github?

I really appreciate if someone can help me out of this. I think I misunderstood how heaven or fabric works. Thank you!

This is quite important to self-host heaven as we do not want to introduce heroku.

Hi!

GitHub gave some love to the Deployment API (https://developer.github.com/changes/2016-04-06-deployment-and-deployment-status-enhancements/) recently. There are a few interesting things, such as the environment_url field to access the application.

My question is: how would you see this feature implemented? I am wondering "who" is responsible for defining this value: should it be sent by hubot-deploy (or any other tool that sends deployment events with a (custom) payload), or should it be determined by Heaven?

As a hubot-deploy + heaven user with a "fixed" staging env, I would like to define the environment_url in the apps.json file, but it would mean having an array of URLs for each environment (or have environment_<name>_url params like for Heroku app name).

On the other hand, Heaven is not aware of the URLs of the apps it deploys.

Had some questions regarding documentation:

• Is the correct webhook for heaven http://<url_for_heave>/events? I read the documentation a number of times, but could not find this information.
• I noticed that heaven uses the postgresql plugin, but in config/database.yml, sqlite3 is used instead. Where is postgresql used? Is it still needed?
• What should the OAuth authorization callback URL be for generating a client id and secret?

Hi,

Whenever I deploy something with Heaven, I get the deploy start/end messages at the same time (when the deploy ends) in my chat service (Slack), even though the deployment takes 10 minutes. Why is that?

I'm using a custom provider for our stack, which is available here: https://github.com/pagarme/heaven/blob/master/lib/heaven/provider/deplorator.rb

Thanks!

Hi!

I have installed heaven on Heroku, and successfully deployed my app using hubot-deploy, and so on. Everything seems to work fine under the hood, however when I first browsed heaven, I got an error telling me that the page did not exist:

Heroku logs say the route does not match anything:

ActionController::RoutingError (No route matches [GET] "/resque"):
[...]

Any hints on what happened? I still can't access anything at this URI. Is there any "web view" on heaven?

Thank you!
William

Looking from the documentation it is not clear how is this controlled. To me it looks like anyone can register webhook in Github with http://my-heaven-server/events and deploy their applications on my private servers. Is heaven secure, can someone explain how the security works here?

Is it worth looking into abstracting the "logging" which is currently using Gists into maybe being configurable?

Downloading the archive vs cloning the repository is a detail of the provider I think it would be nice to configure or change altogether.

In fact, using the archive link may be the better route for all deploys. The reason being is you can download a 3GB git repo as a 25MB tarball a lot faster.

Opening this issue after a discussion in atmos/hubot-deploy#15.

I currently get this error after creating a deploy with a task of deploy:lock or deploy:unlock and the provider set to capistrano:

cap aborted!
Don't know how to build task 'deploy:lock'

@atmos What do you think makes most sense for these tasks: To give handling responsibility to the chosen provider or to intercept and handle these tasks before a deployment provider is involved?

I have an application that runs on Ruby 2.2.2 and I have the Ruby version specified in the Gemfile: ruby '2.2.2'.

When I try to deploy with heaven, I get the message:

Your Ruby version is 2.1.2, but your Gemfile specified 2.2.2

Is there any way I can deploy a Rails application with a different version of Ruby than heaven itself?

I'm running into a pretty strange problem where DEPLOYMENT_PRIVATE_KEY is not getting used in my heroku deploy of heaven master.

I believe I have tracked down the issue though. Check this out:

https://github.com/atmos/heaven/blob/master/app/models/deployment/credentials.rb#L6

The ssh config and private key gets put in /tmp/some-crazy-hash/.ssh, and then the $HOME variable gets overridden. That means when ssh goes to look for its config, it should look there.

However, on Heroku cedar-14 (OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.6, OpenSSL 1.0.1f 6 Jan 2014), ssh does not look in the $HOME variable! It is using the home directory from /etc/passwd (/app) to find the ssh config, and does not find it there.

This is apparently normal behavior for openssh - see this patch where they added a little notice in the README:

OpenSSH never uses $HOME to search for user config files but the
value in the pw_dir field in /etc/passwd.

It seems that having heaven download archives instead of cloning the repo when using bundler_capistrano provider completely broke more than half of our service's deployments. This is partly due to some projects doing things with git submodules or older cap 2 trying to look up the head commit locally.

This change breaks so many things, that I'd like to have it be configurable so we can at least somehow have a way to make everything compatible again without having to have entire deployment infrastructure down while tracking down and fixing unknown things that are caused by not being in a git repo. Capistrano also behaves slightly differently if you give it sha's (like autodeploy does) or branches so the breakages can be subtle.

Clicked on the 'Deploy to Heroku' button, entered all the required config variables. All was going well and then boom. Heroku isn't happy - it won't complete deployment when using the web interface.

Seems weird/overkill that a deprecation warning stops it from finishing - is there a way around this?

See screenshot here - http://files.artificial.io/image/3K1Q3x1g3T0G

Full message from the 'Run scripts & scale dynos' section below:

DEPRECATION WARNING: The configuration option `config.serve_static_assets` has been renamed to `config.serve_static_files` to clarify its role (it merely enables serving everything in the `public` folder and is unrelated to the asset pipeline). The `serve_static_assets` alias will be removed in Rails 5.0. Please migrate your configuration files accordingly. (called from block in tsort_each at /app/vendor/ruby-2.2.2/lib/ruby/2.2.0/tsort.rb:226)
Migrating to CreateDeployments (20140329200427)
== 20140329200427 CreateDeployments: migrating ================================
-- create_table(:deployments)
   -> 0.0213s
== 20140329200427 CreateDeployments: migrated (0.0214s) =======================

Migrating to CreateRepositories (20140728040201)
== 20140728040201 CreateRepositories: migrating ===============================
-- create_table(:repositories)
   -> 0.0203s
-- add_column(:deployments, :repository_id, :integer)
   -> 0.0023s
== 20140728040201 CreateRepositories: migrated (0.0354s) ======================

Full build log can be seen here https://gist.github.com/johnnybridges/365ec66a353deb3105e8

Thanks!

Hello,
I am trying to install heaven, but, I came up with this doubt about the Developer applications that I must create to provide:

• GITHUB_TOKEN
• GITHUB_CLIENT_ID
• GITHUB_CLIENT_SECRET

Which Authorization callback URL should I provide to Github ?
Should this URL be valid or just a fake one to get the necessary information ?

Check this deployment gist for a failed deployment example: https://gist.github.com/capybot/de8e08da4eb52270f409

After debugging and trying to understand how it gets the tarball, I found that, on heroku, curl will not create directories if it doesn't exists, so we must create working_directory before fetching source code.

The idea is to do a FileUtils.mkdir_p(File.dirname(archive_path)) before this line:

Deploys today at my office have been failing due to an Internal Server Error returned from Octokit (Octokit::InternalServerError). The provider will run (and usually succeed) but when it comes time to update the deployment gist, a 500 error is returned from GitHub and the entire deployment "fails".

It seems that from c663ce8 onward, this error and any other StandardErrors are rescued, but the 500s still occur on output update so the deployment gist usually reads something like:

stdout

Deployment 46955 pending

Not very helpful at all.

Has anyone encountered the same problem and/or been able to dig up a cause? The content provided to Octokit seems to be pretty standard Git and deployment output. I wasn't able to find a more detailed response from GitHub while digging around OctoKit.

stderr

  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
  100   817    0   703  100   114   1028    166 --:--:-- --:--:-- --:--:--  1027
  100  1574    0  1460  100   114   2135    166 --:--:-- --:--:-- --:--:--  2134

stdout

HEAD is now at 4e78c80 Commit message
INFO[66101a10] Running /usr/bin/env mkdir -p /tmp/app/ on staging.app.com
INFO[66101a10] Finished in 0.445 seconds with exit status 0 (successful).
INFOUploading /tmp/app/git-ssh.sh 100.0%
INFO[5afdca0f] Running /usr/bin/env chmod +x /tmp/app/git-ssh.sh on staging.app.com
INFO[5afdca0f] Finished in 0.057 seconds with exit status 0 (successful).
INFO[cac5e680] Running /usr/bin/env mkdir -pv /var/www/app/shared /var/www/app/releases on staging.app.com
INFO[cac5e680] Finished in 0.057 seconds with exit status 0 (successful).
INFO[35bf4698] Running /usr/bin/env mkdir -pv /var/www/app/shared/log /var/www/app/shared/tmp/pids /var/www/app/shared/tmp/cache /var/www/app/shared/tmp/sockets /var/www/app/shared/vendor/bundle on staging.app.com
INFO[35bf4698] Finished in 0.058 seconds with exit status 0 (successful).
INFO[1a78c1d5] Running /usr/bin/env mkdir -pv /var/www/app/shared on staging.app.com
INFO[1a78c1d5] Finished in 0.059 seconds with exit status 0 (successful).
INFOThe repository mirror is at /var/www/app/repo
INFO[fb385612] Running /usr/bin/env git remote update on staging.app.com
INFO[fb385612] Finished in 1.163 seconds with exit status 0 (successful).
INFO[85b03637] Running /usr/bin/env mkdir -p /var/www/app/releases/20140818223457 on staging.app.com
INFO[85b03637] Finished in 0.064 seconds with exit status 0 (successful).
INFO[f59bb870] Running /usr/bin/env git archive master | tar -x -C /var/www/app/releases/20140818223457 on staging.app.com
INFO[f59bb870] Finished in 0.342 seconds with exit status 0 (successful).
INFO[935dcf39] Running /usr/bin/env mkdir -pv /var/www/app/releases/20140818223457 on staging.app.com
INFO[935dcf39] Finished in 0.057 seconds with exit status 0 (successful).
INFO[89d5ebfb] Running /usr/bin/env ln -s /var/www/app/shared/.env /var/www/app/releases/20140818223457/.env on staging.app.com
INFO[89d5ebfb] Finished in 0.056 seconds with exit status 0 (successful).
INFO[fcfd02c4] Running /usr/bin/env mkdir -pv /var/www/app/releases/20140818223457 /var/www/app/releases/20140818223457/tmp /var/www/app/releases/20140818223457/tmp /var/www/app/releases/20140818223457/tmp /var/www/app/releases/20140818223457/vendor on staging.app.com
INFO[fcfd02c4] Finished in 0.058 seconds with exit status 0 (successful).
INFO[2fa216e5] Running /usr/bin/env ln -s /var/www/app/shared/log /var/www/app/releases/20140818223457/log on staging.app.com
INFO[2fa216e5] Finished in 0.057 seconds with exit status 0 (successful).
INFO[921415b8] Running /usr/bin/env ln -s /var/www/app/shared/tmp/pids /var/www/app/releases/20140818223457/tmp/pids on staging.app.com
INFO[921415b8] Finished in 0.057 seconds with exit status 0 (successful).
INFO[6c5c1f60] Running /usr/bin/env ln -s /var/www/app/shared/tmp/cache /var/www/app/releases/20140818223457/tmp/cache on staging.app.com
INFO[6c5c1f60] Finished in 0.058 seconds with exit status 0 (successful).
INFO[4fb56c9e] Running /usr/bin/env ln -s /var/www/app/shared/tmp/sockets /var/www/app/releases/20140818223457/tmp/sockets on staging.app.com
INFO[4fb56c9e] Finished in 0.056 seconds with exit status 0 (successful).
INFO[c6906fc9] Running /usr/bin/env ln -s /var/www/app/shared/vendor/bundle /var/www/app/releases/20140818223457/vendor/bundle on staging.app.com
INFO[c6906fc9] Finished in 0.056 seconds with exit status 0 (successful).
INFO[d8e002ee] Running /usr/bin/env bundle install --path /var/www/app/shared/bundle --without development test --deployment --quiet on staging.app.com
INFO[d8e002ee] Finished in 0.593 seconds with exit status 0 (successful).
INFO[6fc2147d] Running bundle exec rake assets:precompile on staging.app.com
INFO[6fc2147d] Finished in 5.608 seconds with exit status 0 (successful).
INFO[e25fdce5] Running /usr/bin/env cp /var/www/app/releases/20140818223457/public/assets/manifest* /var/www/app/releases/20140818223457/assets_manifest_backup on staging.app.com
INFO[e25fdce5] Finished in 0.059 seconds with exit status 0 (successful).
INFO[292428bb] Running /usr/bin/env cd /var/www/app/releases/20140818223457 && source .env && bundle exec rake db:migrate on staging.app.com
INFO[292428bb] Finished in 3.911 seconds with exit status 0 (successful).
INFO[a748f389] Running /usr/bin/env rm -rf /var/www/app/current on staging.app.com
INFO[a748f389] Finished in 0.057 seconds with exit status 0 (successful).
INFO[2f09767a] Running /usr/bin/env ln -s /var/www/app/releases/20140818223457 /var/www/app/current on staging.app.com
INFO[2f09767a] Finished in 0.058 seconds with exit status 0 (successful).
INFO[223f3e93] Running /usr/bin/env cd /var/www/app/current && kill -USR2 $(cat /var/www/app/shared/tmp/pids/unicorn.pid) on staging.app.com
INFO[223f3e93] Finished in 0.060 seconds with exit status 0 (successful).
INFO[9e470e76] Running /usr/bin/env cd /var/www/app/current && source .env && bundle exec sidekiq -d -i 0 -P /var/www/app/shared/tmp/pids/sidekiq.pid -e $RACK_ENV -c $SIDEKIQ_WORKERS -q default -L /var/www/app/current/log/sidekiq.log on staging.app.com
INFO[9e470e76] Finished in 0.784 seconds with exit status 0 (successful).
INFOKeeping 3 of 4 deployed releases on staging.app.com
INFO[9864c1d5] Running /usr/bin/env rm -rf /var/www/app/releases/20140808161311 on staging.app.com
INFO[9864c1d5] Finished in 0.174 seconds with exit status 0 (successful).
Notifying NewRelic
Notifying Honeybadger
Honeybadger Notification Complete
INFO[694775c8] Running /usr/bin/env echo \"Branch master (at 4e78c80) deployed as release 20140818223457 by app; \" >> /var/www/app/revisions.log on staging.app.com
INFO[694775c8] Finished in 0.059 seconds with exit status 0 (successful).

heaven on the heroku, my repo was deploied on the server use capistrano.
When heaven go to login to the server, it need password.
The report gist is here.

I put the pub key to the server's authorize_keys file, and
heroku config:set DEPLOYMENT_PRIVATE_KEY=my private key
but it still need the password, is there any ideas? Thx.

I can't tell when particular lines of stdout happened in relation to stderr, which is annoying when I have errors on stderr, and useful information on stdout.

One option: put all the logs in the same file, but put "STDERR" or "STDOUT" before lines so you know where it came from.

I have code for this, just wanna see if you think it's a decent approach.

My title probably doesn't make sense. So I'll try and explain. As far as I can see, heaven doesn't allow for a workflow similar to the following:-

• Receive deploy event from Github
• Trigger deploy process.
• Wait for response (pingback) to say this has been done/failed
• Send Deploy Status Event to Github

As far as I can tell at the moment, when the deploy is triggered, resque runs, and is expected to return a pass/fail which it immediately returns to Github.

I'd want to be able to do something like, create an AMI in AWS. This would take a significant amount of time, and I can have SNS send a notification (or similar) when this (long running) process is done. However, as far as I can see, Heaven won't cater for this, and has to sit around polling for the AMI build to be finished.

Am I missing something here? If I'm not - can you give me any pointers for the best way to go about adding this in?

The app.json file specifies a dyno formation size of "1X", but Heroku recently changed the default tier for new apps and 1X isn't a valid size anymore. My suggestion would be to remove the size completely so that the cheapest type is created.

If a deploy takes longer than DEPLOY_TIMEOUT (by default 5min) the deployment just fails without explanation and the deployment log is completely emtpy. This should be handled as a separate case, logs should be pushed to gist and a note about job timeout should be added to the log. Probably should add a new type of notify message too.

I'm also thinking if the deployments should have a hook for canceling them nicely so a possible rollback etc can be done.

if you give the github auth key incorrect permissions (and so cloning the repo 403s), then the gist output is empty, and there is no log anywhere of the error.

Two suggestions:

1. always log stdout/stderr to Rails.logger when a job fails (I can PR my code for this if you'd like)
2. This shouldn't result in no gist output. Entirely unsure why that's the case.

We had a few bits of pain here - needed to add a bunch of permissions, and because the person doing the permission adding wasn't the person working on getting heaven up and running, there was a lot of back and forth (across an 8 hour timezone difference as well).

I think a screenshot of the permissions screen for a working auth key would be helpful somewhere in the getting started documentation.

Occasionally, I'll get git output like the following during deploys:

From https://github.com/dscout/dscout
542f131..9fcc475 master -> origin/master
error: unable to read sha1 file of Gemfile (df8c83095564185f146e937a36f5a30267d747f7)
error: unable to read sha1 file of Gemfile.lock (de830d7489153e2e1d9d14708ca19a9e841b1c4d)
error: unable to read sha1 file of app/middleware/content_type_correction.rb (2fbfe4469a82722ee8f9bf3212c1282541603e92)
error: unable to read sha1 file of app/middleware/font_access_headers.rb (22d7334324f748d4585c225b7cbc6a2d8b098b23)
error: unable to read sha1 file of app/models/mission.rb (9b8d0a941bde2142a63dd2368025282638c6bc02)
error: unable to read sha1 file of app/models/snippet.rb (e11c908c36498141a298434050f15c90b7b4a8d5)
error: unable to read sha1 file of app/services/assignment_destroyer.rb (bbff88562509f5cb2c2f135bb74d6bb24afac3d9)
error: unable to read sha1 file of app/services/group_messenger.rb (f603f81c3811f2ed19b3180d015538c328c603eb)
error: unable to read sha1 file of config/application.rb (f82ae6f44d58fefb1e1fa7a9a4fa31b77f96f54b)
error: unable to read sha1 file of spec/factories/message_factory.rb (db36db83391e9ed057595c6d772e575309518871)
error: unable to read sha1 file of spec/requests/v2/messaging_spec.rb (2aea3ea57a1655f6eb294f904563dd05c8f1c315)
error: unable to read sha1 file of spec/services/assignment_destroyer_spec.rb (36a1c1095dd7f5b6927e6445edec5357ede59d60)
fatal: Could not reset index file to revision '9fcc475a5b510f8ee76bf945b96b99346e685b89'.
 % Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed

0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
100 809 0 695 100 114 1301 213 --:--:-- --:--:-- --:--:-- 1299
100 1573 0 1459 100 114 2730 213 --:--:-- --:--:-- --:--:-- 2727

The deploy continues on, which usually doesn't make a big difference when using a Capistrano provider. I'm using Capistrano v3. We don't usually alter the Capistrano configuration, and the remote server will fetch the git repository itself.

But, the working directory repo obviously doesn't checkout to the right sha. And for other providers, this will be more problematic (such as deploying straight to S3).

Has anyone run into this problem on their own setups? Any ideas towards fixing this problem?

I usually end up deleting the working directory which forces heaven to re-clone the repository during the next deploy.

I suppose another question is: should the deploy continue on if any task during a provider fails, or should the entire deploy fail immediately and ignore any following tasks.

I tried several times to deploy the app in heroku but I never could finish the process.

Is there any special stuff to do ?

Well, looks like Heroku deprecated their Build Result endpoint today, rendering Heaven not so useful, as the output call is getting 410 status codes back. The result of this is that successful deploys look like failures. Not sure if this is on your radar at all?

Hey atmos,

Would a New Relic deployment notifier be a welcome addition here?
It deviates from the chat notification theme but it sure is useful.

It seems like all the providers are trying to read the task from wrong place. Capistrano, BundlerCapistrano and Fabric all have

def task
  name = custom_payload && custom_payload["task"] || "deploy"
  ...
end

where custom_payload comes from DefaultProvider as

def custom_payload
  @custom_payload ||= data["deployment"]["payload"]
end

However the deployments api has the task attribute directly under deployment and not in the payload.

Hi @atmos, I am sorry to bother you since this issue is not entirely related to Heaven.

I am wondering how the github_authenticate method (used here: https://github.com/atmos/heaven/blob/master/config/routes.rb#L4-L6) should deal with assets?

I use a self-hosted version of Heaven, which works well except for the resque-web dashboard. All assets have to be double-checked by the GitHub OAuth dance, which does not (always) work well (I have to refresh the page several times to get the dashboard with the assets correctly loaded):

The other issue is that I am not really a Rails expert, so I may miss an obvious solution. In addition, "assets" are not served by the web server (nginx) since I don't know where resque's assets are located.

Thank you,
Will

Redis services other than openredis have other ENV vars (I'm using Heroku's Redis Cloud add-on which provides REDISCLOUD_URL), it would be nice to have a generic REDIS_URL fallback for the other options.

Hey guys, to run heaven with capistrano 3 projects on my end i had to do this change HearstDigitalStudios/heaven@b60bc05 and change capistrano version in my Gemfile obviously.
IIRC – capistrano2 is not sensitive to argument order, but capistrano3 is – so maybe it make sense to set an and order to cap <env> <task> <additional args> as a default behaviour, so it would make things easier for those like me, who use cap3 and willing to use heaven as well.

Is there a reason why there is a default value for the GitHub team?

If a user fails to add the GITHUB_TEAM_ID env var, members of the team with id 696075 would be able to access their /resque page.

I can't see what team 696075 refers to, or if it even exists.

The button needs to be in README.md because Heroku looks at the referrer and cannot currently find the app.json

I'm only deploying to heroku right now. I'd like to make it easier to use other people's services if people deploy there.

I see this was discussed in #45, but as that is now closed and I don't see another issue open for this, I'll open one....

We maintain a separate branch with auto-deploy functionality explicitly removed because we want to control when our production environment is updated (semi-continunuous-deployment, if you will).

In testing some new functionality I'm working on for a PR, I forgot about that and was running heaven's master branch and whoops! Auto-deploy to production.

I would really appreciate some way to disable this functionality, or even better, change it to opt-in.

The heroku stuff showed off that the most difficult environmental variable to identify is the team id. Make this easier to find.

undefined method `join' for "fab -R production deploy:branch_name=master":String

This is due to local_log_file:

    unless last_child.success?
      fail StandardError "Task failed: #{cmds.join(" ")}"
    end

It successfully updates to the new code but you never get a completed message due to Resque::DirtyExit exceptions being thrown as the process completes.