atmos / heaven Goto Github PK
View Code? Open in Web Editor NEW:walking: Rails app for GitHub Flow
License: MIT License
:walking: Rails app for GitHub Flow
License: MIT License
This is quite important to self-host heaven as we do not want to introduce heroku.
I tried several times to deploy the app in heroku but I never could finish the process.
Is there any special stuff to do ?
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!
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
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?
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.
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.
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.
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:
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:
Rails.logger
when a job fails (I can PR my code for this if you'd like)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.
Had some questions regarding documentation:
http://<url_for_heave>/events
? I read the documentation a number of times, but could not find this information.postgresql
plugin, but in config/database.yml
, sqlite3 is used instead. Where is postgresql
used? Is it still needed?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
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.
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.
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.
Is it worth looking into abstracting the "logging" which is currently using Gists into maybe being configurable?
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.
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.
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 ?
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
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
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.
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.
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.
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.
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 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?
The button needs to be in README.md because Heroku looks at the referrer and cannot currently find the app.json
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.
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.
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.
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.
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?
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?
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
The heroku stuff showed off that the most difficult environmental variable to identify is the team id. Make this easier to find.
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!
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.
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?
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.
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 StandardError
s 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).
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!
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:-
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?
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.
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:
any idea, why it could happen?
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?
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.