If the environment fails to deploy, however, it will look more like this:
```json theme={null}
{
"state": "failure",
"statuses": [
{
...
"state": "failure",
"description": "Platform.sh: Environment deployment failed",
"target_url": "http://pr-35-qsr3ccy-o3fc5w4n5iumy.eu-3.platformsh.site/",
"context": "platformsh",
}
],
…
}
```
Exactly the same, just with a different `state` message.
The target URL isn’t updated based on the failed deployment, so our **Details** link will simply take us to the
environment URL which has failed to deploy. The failed URL doesn't help us much here, but it does seem like the
opportune place to insert our activity link. So, from here we have a clear goal: detect the failed deployment and update
the `target_url` attribute with our failed activity link.
We start by creating some space for our
[workflows](https://docs.github.com/en/actions/learn-github-actions/workflow-syntax-for-github-actions)
```bash {filename="Terminal"} theme={null}
mkdir .github
mkdir .github/workflows
touch .github/workflows/post-deploy.yaml
```
In a `.github/workflows/post-deploy.yaml` file we can start building out the action. In the first lines, we define when
this action should occur. For now, we can simply say that it should run on every push to all branches except our default
branch - we’ll add some logic later on to make sure this only runs on pull requests. After that, we can expose a CLI
token and a GitHub token as environment variables to be used by the action.
```yaml {filename=".github/workflows/post-deploy.yaml"} theme={null}
---
name: Post-deploy
on:
push:
branches-ignore:
- "main"
env:
PLATFORMSH_CLI_TOKEN: ${{ secrets.CLI_TOKEN }}
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
```
> You can add your Platform.sh CLI token as a repository or organization level
> [secret](https://docs.github.com/en/actions/security-guides/encrypted-secrets).
Now it’s time to define a few jobs. The first one is simply meant to determine:
* Are we working from a pull request?
* What is the URL (`target_url`) of the environment associated with the pull request?
* What’s the status of the deployment?
Below is the snippet for the job `build` we’ll use to do this.
```yaml {filename=".github/workflows/post-deploy.yaml"} theme={null}
jobs:
build:
runs-on: ubuntu-latest
name: "Get environment URL"
outputs:
commit_status: ${{ steps.status.outputs.env_status }}
env_url: ${{ steps.url.outputs.env_url }}
integration_status: ${{ steps.wait.outputs.integration }}
steps:
- uses: actions/checkout@v2
- name: "Await deployment"
id: wait
run: |
COMMIT_STATUS="pending"
sleep 10
STATUSES=$(curl -s https://api.github.com/repos/$GITHUB_REPOSITORY/statuses/$GITHUB_SHA | jq -r 'length')
if [ $STATUSES == 0 ]; then
echo "Not on a Platform.sh integrated environment. Skipping."
echo "::set-output name=integration::none"
else
until [ "$COMMIT_STATUS" == "success" ] || [ "$COMMIT_STATUS" == "failure" ]; do
sleep 30
ENV_URL=$(curl -s https://api.github.com/repos/$GITHUB_REPOSITORY/statuses/$GITHUB_SHA | jq -r '.[0].target_url')
COMMIT_STATUS=$(curl -s https://api.github.com/repos/$GITHUB_REPOSITORY/statuses/$GITHUB_SHA | jq -r '.[0].state')
echo "Waiting for Platform.sh environment to deploy ...."
echo " - $GITHUB_SHA"
echo " - $COMMIT_STATUS"
echo " - $ENV_URL"
done
echo "Environment deployed. Finished."
echo "::set-output name=integration::platformsh"
fi
- name: "Pass status"
id: status
if: steps.wait.outputs.integration == 'platformsh'
run: |
COMMIT_STATUS=$(curl -s https://api.github.com/repos/$GITHUB_REPOSITORY/statuses/$GITHUB_SHA | jq -r '.[0].state')
echo "::set-output name=env_status::$COMMIT_STATUS"
- name: "Pass URL"
id: url
if: steps.wait.outputs.integration == 'platformsh'
run: |
ENV_URL=$(curl -s https://api.github.com/repos/$GITHUB_REPOSITORY/statuses/$GITHUB_SHA | jq -r '.[0].target_url')
echo "::set-output name=env_url::$ENV_URL"
```
In summary, we are:
* Placing a request on the Status API.
* Verifying that this is associated with an environment on Platform.sh (deploying from a Pull request).
* Waiting for the status to update from `pending` to `success` or `failure`. In the case above, we’re literally placing
requests on the status and waiting for it to change. This is unlikely to be the most efficient way of doing this, but
it works - so ship it.
* Passing that status and `target_url` value out of job `build`, so that those values will be accessible from subsequent
jobs.
Now that the environment has deployed, we can pipe in these outputs to build the activity link in a new job called
`displaylogs`:
```yaml {filename=".github/workflows/post-deploy.yaml"} theme={null}
displaylogs:
name: "Display logs on failed deploy"
runs-on: ubuntu-latest
needs: build
if: needs.build.outputs.commit_status == 'failure'
steps:
- name: "Install the Platform.sh CLI"
run: |
# Install Platform.sh CLI
curl -sS https://platform.sh/cli/installer | php
- name: "Retrieve the logs"
id: activity
run: |
# Get data.
IFS='-' read -ra my_array <<< "${{ needs.build.outputs.env_url }}"
ENVIRONMENT="pr-${my_array[1]}"
IFS="." read -ra my_array <<< "${my_array[3]}"
PROJECT="${my_array[0]}"
ACTIVITY=$(~/.platformsh/bin/platform project:curl -p $PROJECT /environments/$ENVIRONMENT/activities | jq -r '.[0].id')
LOG_URL=https://console.platform.sh/projects/$PROJECT/$ENVIRONMENT/log/$ACTIVITY
echo " * PROJECT: $PROJECT"
echo " * ENVIRONMENT: $ENVIRONMENT"
echo " * ACTIVITY: $ACTIVITY"
echo " * LOGS: https://console.platform.sh/projects/$PROJECT/$ENVIRONMENT/log/$ACTIVITY"
echo "::set-output name=log_url::$LOG_URL"
- name: "Update integration target_url"
run: |
curl -s --location --request POST --header "Authorization: Bearer $GITHUB_TOKEN" \
--header 'Content-Type: application/json' \
--data-raw '{"state": "failure", "target_url": "${{ steps.activity.outputs.log_url }}", "context": "platformsh", "description": "Platform.sh: Failed to deploy environment. View the activity log details."}' \
https://api.github.com/repos/$GITHUB_REPOSITORY/statuses/$GITHUB_SHA
```
You’ll notice that job `displaylogs` `needs` the job `build` - it will only run after `build` has completed, and it will
be able to access its outputs from the namespace `needs.build.outputs.X`. It’s from this that we can restrict
`displaylogs` to make our update to only those cases when the environment deployment has failed. After this check, the
job
* Installs the Platform.sh CLI.
* Uses the `target_url` to retrieve our project ID, and environment name for the pull request.
* Places a request on the `projects/environments/:environment/activities` endpoint on the Platform.sh API to get the
most recent failed activity (and its ID).
* Builds the activity log URL from the project ID, environment ID, and activity ID at
[console.platform.sh](https://console.platform.sh).
* Places a final request onto the GitHub Status API, which updates the `target_url` value from Platform.sh to our
activity URL.
With these changes in place, any failed deployment pushed to GitHub will be updated in this way. A successful deployment
will provide the environment’s URL in the **Details** link of the integration status as usual, but anything that fails
will take our team directly to the failed logs so that we can investigate what went wrong.
You can find the Gist of the GitHub action described above
[here](https://gist.github.com/chadwcarlson/96d6c4cb8c6b371ab04e256554dde728/1a608fd4fff4042aa2116a32bb925b482a9a2100).
Let us know where you’d like to see shareable activities by
[joining the Platform.sh Slack](https://chat.platform.sh), and share with us how you’ve used it in your own workflow on
our [Community](https://community.platform.sh).