Why github.ref_name is empty?

[brunocalza]

Select Topic Area

Question

Body

Suddenly my jobs started failing because github.ref_name is coming empty.

The jobs are triggered when a new release is created.

Here's the workflow code: https://github.com/tablelandnetwork/go-tableland/actions/runs/5927734903/workflow

[arafajs]

The github.ref_name context variable is only available when the workflow is triggered by a push event to a branch or tag. Since your workflow is triggered by a release creation event, the github.ref_name context variable will be empty.

To get the tag name in this case, you can use the GITHUB_REF context variable. The GITHUB_REF variable contains the full ref that triggered the workflow, including the branch or tag name.

For example, if the workflow is triggered by a release creation event for the tag v1.2.3, the GITHUB_REF variable will be set to refs/tags/v1.2.3.

You can then use the GITHUB_REF variable to get the tag name by removing the refs/tags/ prefix. For example:

echo "Tag name: ${{ env.GITHUB_REF#refs/tags/ }}"
This will print the tag name, which in this case is v1.2.3.

You can update your workflow to use the GITHUB_REF variable as follows:

on: release:
  types:
    - published

jobs:
  get_tag_name:
    runs-on: ubuntu-latest
    steps:
      - name: Get tag name
        run: echo "Tag name: ${{ env.GITHUB_REF#refs/tags/ }}"

This workflow will now print the tag name when a new release is created.

[brunocalza]

Strange. github.ref_name was working fine.

Anyways, tried ${{ env.GITHUB_REF#refs/tags/ }} but I'm getting the error: Unexpected symbol: 'GITHUB_REF#refs/tags/'. Located at position 5 within expression: env.GITHUB_REF#refs/tags/ now.

[mike-carey]

The github.ref_name context variable is only available when the workflow is triggered by a push event to a branch or tag. Since your workflow is triggered by a release creation event, the github.ref_name context variable will be empty.

Where did you get this information? Nowhere in the docs does it say that this variable is specific to the push event. Others that are specific to a particular type of event explicitly state that they only work in certain cases.

github.ref_name (string) The short ref name of the branch or tag that triggered the workflow run. This value matches the branch or tag name shown on GitHub. For example, feature-branch-1.

Example of explicit only:

github.base_ref (string) The base_ref or target branch of the pull request in a workflow run. This property is only available when the event that triggers a workflow run is either pull_request or pull_request_target.

[brunocalza]

I used github.event.release.tag_name and it fixed the issue. Thanks!

[jpw1991]

Thank you, this helped me

[mike-carey]

actions/runner#2788

[mike-carey]

This has not happened to us in a while. Today, I had it happen again for a single workflow run. Our release pipeline passes github.ref_name as the version.

1. Cut a release, the github.ref_name was empty.
2. Reran all jobs, the variable was still empty string.
3. Cut a new release with no changes but the tag incremented by 1, github.ref_name was set.

Hopefully this does not happen again, but wanted to throw out here in case others are having the same inconsistencies again.

[panserbjorn]

Thanks for the fix, these steps worked for our deployment.

We had the same problem at the same time you had it.
A possible reason might be that the creation of the release wasn't successful.
In our case the release we did on Friday was generated successfully, but only the tag is visible. On the release tab in GitHub there is no trace of the release.

The new release (today) was correctly generated and it appears in the release tab on GitHub.

[msaktor]

What works for me more consitently for both pull_request and pull_request_review events is this

branch: github.event.pull_request.head.ref
base of PR: github.event.pull_request.base.ref

[samus-aran]

We can see that this is still a popular discussion we want to add additional info as to why the github.ref may be empty so we can guide users to the correct documentation.

Following @arafajs reply It's important to note that the behavior of github.ref_name depends on the event that triggers the workflow. For instance:

• For push events, github.ref_name corresponds to the branch or tag that was pushed.
• For release events, the release tag can be accessed via github.event.release.tag_name, while github.ref_name might not always provide the expected value.
• For other triggers like pull_request, the variable behaves differently, often pointing to the merge branch or base branch.

We recommend reviewing the GitHub Docs on default environment variables for a deeper understanding of variable behavior across different events.

Acknowledging the users experiencing inconsistencies we have shared this feedback with our internal teams.

[ddebrunner]

That page leads to the variables reference which states for GITHUB_REF:

For workflows triggered by release, this is the release tag

Do the docs need to be updated to reflect "For release events, [...], while github.ref_name might not always provide the expected value." ?

[asarkar]

I also found GITHUB_REF_NAME to be empty on a job that's manually triggered (workflow_dispatch). But rlespinasse/github-slug-action has no problems making it available as GITHUB_REF_NAME_SLUG. It'll be nice to have GitHub fix this problem, as it's not safe to have third-party actions have access to env variables.