How to get base ref branch in a GitHub Actions workflow?

[merc1er]

I want to know against which base a branch has a pull request open (if any). For example I have a dev branch and I want to perform a certain job ONLY if it has a PR open against master.

In the docs, it says we can see the base ref with github.base_ref. But it also says:

This property is only available when the event that triggers a workflow run is either pull_request or pull_request_target.

Is there a way to know the base ref on every push to dev?

This is my code, but this only works once when I create the PR (and not on every push):

jobs:
  my-job:
    runs-on: ubuntu-latest
    if: ${{ github.base_ref == 'refs/heads/dev' }}
    ...

[airtower-luna]

merc1er:

Is there a way to know the base ref on every push to dev?

No, because a push doesn’t have a “base ref”, just a before and after state on the branch that’s being pushed.

If you want to act based on a PR you need to use one of the PR-related events (or iterate over PRs using the API, but that could get messy and run afoul of rate limits).

[thalysonalexr]

why not have?
in my local machine i do checkout in branch X, i pushed info for github. Github not storage this information anywhere local?

[airtower-luna]

It's because there is no "base". In a PR you have a "head branch" which you want to merge into a "base branch". Their respective refs are called "head ref" and "base ref".

In a push there is only one branch. So the push event simply has the information that the branch was at commit A before the push, and at commit B after.

[jsoref]

Git is structured around commits.
Tags and branches are just pointers to commits.

Most other things are educated guesses.

If someone tells git "change this branch from pointing at commit A to pointing to commit B", then people can reasonable conclude that the branch moved from A to B.

The basic way this happens is:

git checkout branch-name
touch file
git add file
git commit -m 'Adding file'

Here, we've added a commit on top of another commit. Obviously it's connected to the previous commit.

It could also happen like this:

git checkout branch-name
git reset --hard $COMMIT_B

In this case, $COMMIT_B isn't necessarily connected to $COMMIT_A.

But, you could have done this locally:

git checkout HEAD~
git branch -D branch-name
git branch -f branch-name $COMMIT_B

In both cases there's no actual relation between $COMMIT_A and $COMMIT_B, and in the second case, there isn't even a continuity between branch-name at $COMMIT_A and branch-name at $COMMIT_B.
But, because when you do a push to github, it knows that branch-name used to be at $COMMIT_A, it can say "well, branch-name used to be $COMMIT_A"

Note that it has no idea what branch $COMMIT_B came from. There could be 0, 2, 3, or more branches pointing to $COMMIT_B. It's also possible there are 0, 4, or 7 tags pointing at $COMMIT_B.

You could also do:

git branch -f branch-name some-tag~5

In which case branch-name is now a distant relative of some-tag but not actually directly related to it.

Or, you could do:

git checkout branch-a
git merge branch-b -m 'merging branch-a and branch-b'
git branch -f branch-name

Here, branch-name is now related to both branch-a and branch-b, but not equal to either.

In each case, you can git push -f origin branch-name and github will have to offer answers.

[thalysonalexr]

thanks so much for perfect and detailed answer

[jsoref]

So, I have special code that looks to see if a git push has a corresponding open PR:

  <a href="https://github.com/check-spelling/check-spelling/blob/624e4ede7c93c6255ad80c08395fc1687b6a3e10/unknown-words.sh#L41-L47" target="_blank" rel="noopener">github.com</a>

check-spelling/check-spelling/blob/624e4ede7c93c6255ad80c08395fc1687b6a3e10/unknown-words.sh#L41-L47

<pre class="onebox"><code class="lang-sh">
  <ol class="start lines" start="41" style="counter-reset: li-counter 40 ;">
      <li>if to_boolean "$INPUT_SUPPRESS_PUSH_FOR_OPEN_PULL_REQUEST"; then</li>
      <li>  pull_request_json=$(mktemp_json)</li>
      <li>  pull_request_headers=$(mktemp)</li>
      <li>  pull_heads_query="$GITHUB_API_URL/repos/$GITHUB_REPOSITORY/pulls?head=${GITHUB_REPOSITORY%/*}:$GITHUB_REF"</li>
      <li>  keep_headers=1 call_curl \</li>
      <li>    "$pull_heads_query" &gt; $pull_request_json</li>
      <li>  mv "$response_headers" "$pull_request_headers"</li>
  </ol>
</code></pre>

  <a href="https://github.com/check-spelling/check-spelling/blob/624e4ede7c93c6255ad80c08395fc1687b6a3e10/unknown-words.sh#L60-L66" target="_blank" rel="noopener">github.com</a>

check-spelling/check-spelling/blob/624e4ede7c93c6255ad80c08395fc1687b6a3e10/unknown-words.sh#L60-L66

<pre class="onebox"><code class="lang-sh">
  <ol class="start lines" start="60" style="counter-reset: li-counter 59 ;">
      <li>elif [ $(jq length $pull_request_json) -gt 0 ]; then</li>
      <li>  (</li>
      <li>    open_pr_number=$(jq -r '.[0].number' $pull_request_json)</li>
      <li>    echo "Found [open PR #$open_pr_number]($GITHUB_SERVER_URL/$GITHUB_REPOSITORY/$open_pr_number) - check-spelling should run there."</li>
      <li>    echo</li>
      <li>    echo '::warning ::WARNING: This workflow is intentionally terminating early with a success code -- it has not checked for misspellings.'</li>
      <li>    echo '::warning ::You should treat this workflow run as if it were SKIPPED state and instead look for a `pull_request_target` workflow for `check-spelling` in the PR.'</li>
  </ol>
</code></pre>

  <a href="https://github.com/check-spelling/check-spelling/blob/624e4ede7c93c6255ad80c08395fc1687b6a3e10/unknown-words.sh#L74-L75" target="_blank" rel="noopener">github.com</a>

check-spelling/check-spelling/blob/624e4ede7c93c6255ad80c08395fc1687b6a3e10/unknown-words.sh#L74-L75

<pre class="onebox"><code class="lang-sh">
  <ol class="start lines" start="74" style="counter-reset: li-counter 73 ;">
      <li>  exit 0</li>
      <li>fi</li>
  </ol>
</code></pre>

You can do all sorts of magical things. Whether you should is a different story. In my case, I like that my action/workflow can run on both push and pull_request(_target) and not cost too much extra/cause too much extra confusion if both are configured.