#### **2. The event**
For this next step, go ahead and open up the file you just created. The first thing we need to do is instruct the GitHub
Actions platform on when this workflow should be triggered via a
[defined event](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows).
To trigger this workflow when a new tag is added, we'll use the
[push event](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#push) with an
[event filter](https://docs.github.com/en/actions/using-workflows/triggering-a-workflow#using-filters) of
[tags](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#onpushbranchestagsbranches-ignoretags-ignore).
If needed, we could also filter for only tags that match a certain pattern, but for this demonstration, we'll allow the
workflow to be triggered when any tag ( `‘*’` ) is added. I'm also going to add a name property so that this workflow
will be easier to identify in the repository's Actions tab.
```yaml {filename=".github/workflows/push-tags.yml"} theme={null}
name: Push to Platform.sh when tagged
on:
push:
tags:
- '*'
```
#### **3. The jobs**
Next, we need to define the [jobs](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobs)
this workflow should run. While unlikely, you don't want to push tags that reference commits that are older than commits
that have already been pushed or on a branch other than our production branch[^1].
To avoid this, create two jobs `should-we-push` which will determine if the tag that was just created references a newer
commit on the correct branch, and a second job `we-should-push` which will handle pushing the new commits to Platform.sh.
All jobs require a `runs-on`
[property](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idruns-on) to
designate the OS of the
[runner](https://docs.github.com/en/actions/using-github-hosted-runners/about-github-hosted-runners/about-github-hosted-runners),
so for both, you can set them to use `ubuntu-latest`.
```yaml {filename=".github/workflows/push-tags.yml"} theme={null}
jobs:
should-we-push:
runs-on: ubuntu-latest
we-should-push:
runs-on: ubuntu-latest
```
By default, jobs run concurrently, but in this case, you want the `we-should-push` job to only run if the
`should-we-push` job determines this tag contains new commits.
To build dependency between the jobs, you need to add a `needs` property to the `we-should-push` job, and an `outputs`
property to the `should-we-push` job so that it can pass information to the `we-should-push` job. Set the
`should-we-push` job to output a value named `push` that is set by the `do-push` step—a step that doesn't exist yet, but
don’t worry, we'll create it shortly.
```yaml {filename=".github/workflows/push-tags.yml"} theme={null}
jobs:
should-we-push:
runs-on: ubuntu-latest
outputs:
push: ${{ steps.do-push.outputs.push }}
we-should-push:
runs-on: ubuntu-latest
needs: should-we-push
```
#### **4. Making sure we need to Push**
Now let's start building out the steps in our `should-we-push` job. By default, your runner's workspace does not contain
the contents of your repository. Before we can evaluate what tags exist, we'll need to checkout our repository into the
workspace on our
[runner](https://docs.github.com/en/actions/using-github-hosted-runners/about-github-hosted-runners/about-github-hosted-runners).
We can use the [actions/checkout action](https://github.com/actions/checkout) to do this task for us.
However, this action’s default is to only fetch a single commit: the ref/SHA that triggered the workflow. We need the
tag history so we can evaluate if the tag triggering the workflow is from newer commits and on the correct branch. To
alter the behavior of this action, we'll use the `with` property and instruct it to instead checkout all history for
tags. We'll also instruct it to checkout the default (production) branch with the `ref` property. We can retrieve that
branch name with the `github` [context](https://docs.github.com/en/actions/learn-github-actions/contexts#github-context).
```yaml {filename=".github/workflows/push-tags.yml"} theme={null}
jobs:
should-we-push:
runs-on: ubuntu-latest
outputs:
push: ${{ steps.do-push.outputs.push }}
steps:
- uses: actions/checkout@v4
with:
fetch-depth: 0
ref: ${{ github.event.repository.default_branch }}
```
Now that we have our repository checked out into our runner's workspace, we can check to see if the current tag is the
tag nearest to the most recent commit in the production branch. To do that, we'll use the git command
[describe](https://git-scm.com/docs/git-describe). This allows us to ensure we're not pushing a tag that has been added
to an old commit, or on another branch and pushing unnecessary commits over to Platform.sh.
Please note, at a later step in the `we-should-push` job you will need to reference the Platform.sh project ID
associated with this repository.
While you are in the repository secrets area of GitHub, go ahead and add another secret for the project ID. To locate
your project's ID, if you are logged into the Platform.sh
[console](https://console.platform.sh/?_utm_medium=Email&_utm_campaign=2022-09-newsletter&_utm_source=devrelcareers),
you can locate your project's ID under the title of your project, to the right of the project's region when viewing the
project's page in the console, as seen below:
Alternatively, from the command line, when in the local copy of your project, you can run the following command:
```bash {filename="Terminal"} theme={null}
❯ platform project:info id
ropxcgtns2wgy
```
In GitHub, add a repository secret of `PROJID` and type/paste in your project ID.
Similar to the first step in the `should-we-push` job, we need to check out our repository into the runner workspace, as
seen below:
```yaml {filename=".github/workflows/push-tags.yml"} theme={null}
we-should-push:
runs-on: ubuntu-latest
needs: should-we-push
env:
PLATFORMSH_CLI_TOKEN: ${{ secrets.PSH_TOKEN }}
if: needs.should-we-push.outputs.push == 'true'
steps:
- uses: actions/checkout@v4
with:
fetch-depth: 0
```
Since `should-we-push` determined we're on the correct branch in the code snippet above, we don't need to include the
`ref` property this time. Now you need to install the Platform.sh CLI.
**Please note**: to keep the sample code below short, we’re `