# Cookbook

These are some additional recipes you can implement in Github Actions!

## Debugging Github Actions

Given that steps in a job can be a script, you can actually perform logging as steps in a job:

```yaml
- name: Logging
  run: |
    echo ${{ github.repository }}
    echo 'Hello!'
```

These will add a step to the job that logs these echos.

## Conditional steps

You can also run steps based on certain conditions (using [expressions](https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/evaluate-expressions-in-workflows-and-actions)). This is particularly useful when you want to only run a step when certain conditions are met.

```yaml
- name: Only run on Windows
  if: ${{ runner.os == 'windows' }}
  run: |
    Write-Output "test output"
```

The above step only runs when the runner OS is Windows.

{% hint style="info" %}
It is very important to note that there are several limitations to what expressions might work in the `if` key. These are dependent on what contexts are available to each part of a step. More information about contexts can be found [here](https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/accessing-contextual-information-about-workflow-runs) and the contexts available to `if` are: `github`, `needs`, `vars`, `inputs` 
{% endhint %}

## Adding environment variables

Given that virtual machine runners run an OS, you will have access to environment variables from within the job through the `env` context. To add to the `env` context, you can use a step:

```yaml
- name: Export environment variables
  run: |
    echo "START=$(date +'%Y-%m-%dT%H:%M:%S')" >> $GITHUB_ENV
```

The above exports a new environment variable `START` into `env` . This can be then accessed via `${{ env.START }}`.

## Matrix strategies

Suppose that you want to verify that a set of changes are not susceptible to backward compatibility issues in a Node.js environment (version `20`), while ensuring that the latest Node.js version is supported as well (version `23`).

You can actually use matrix strategies to verify this information by running the same job across different parameters.

```yaml
jobs:
  example_matrix:
    strategy:
      matrix:
        version: [20, 23]
    steps:
      - uses: actions/setup-node@v4
        with:
          node-version: ${{ matrix.version }}
```

So using the above, we are able to then run the same job `example_matrix` twice with two different node versions: `20` and `23`.