codeship-library / heroku-deployment Goto Github PK

We're currently using my Heroku account (as of #17) to test the Heroku deployment as well as the codeship-deployment-test application.

We should move this to the Codeship Services Heroku account and move the test application to that account as well (or create a new one)

Make the different commands from the Heroku deployment available via a wrapper script and extract certain functionality into this script, e.g

codeship_heroku check_access --app codeship
codeship_heroku deploy --app codeship

When checking for app access, the command will fail if the signed-in user is the owner of the app rather than a collaborator, because the output of the heroku apps command doesn't have a space character after the app name.

For example, if I am the owner of all of my apps, the heroku apps output looks like:

=== [email protected] Apps
my-first-app
my-second-app

But if I am a collaborator, the output looks like:

=== Collaborated Apps
my-first-app             [email protected]
my-second-app            [email protected]

Therefore, this grep command doesn't find a match because it's looking for a space (\s):

heroku apps -A -p | grep -e "^${HEROKU_APP_NAME}\s"

Instead, it should look for a word break (\b):

heroku apps -A -p | grep -e "^${HEROKU_APP_NAME}\b"

Context:
I just switched from Codeship Classic to Docker based builds, and our deploy step doesn't work because there is no .git present in the container.

That led me to look at this repo, via:
https://codeship.com/documentation/docker-integration/heroku/

Looking at this part of your sample deploy script I see you use tar and platform API approach for deployment.

Unfortunately I believe this introduces an issue:

Consider the possibility that a build for a commit older than that which is currently deployed completes it tests, and starts its deployment step. This could happen for a several reasons:

1. An early build was intentionally or accidentally restarted.
2. Two commits were pushed in rapid succession, and timing unpredictability resulted in the later commit's test steps completing prior to the former commit's test steps.

Now:

• When using git based builds, the subsequent attempt to push a commit which is a parent of the most recently pushed commit, results in a pushed branch tip is behind its remote error. However:
• When using the tar-and-platform-API approach suggested here, I believe the deployment would take place regardless.

In the former case the build remains on the most recent code, however:
In the latter case the newer commit would be effectively reverted from the deployment.

To clean up the root directory and make it more clear why there is a Gemfile, Procfile, ... in this repository.