Girhub bit branch determination is not reliable

[konclave]

Bug

Currently, the working branch determination in the Github environment relies on the GITHUB_REF environment variable value.
But this works correctly only if the workflow was triggered by pretty limited number of events: https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows

Only the ones that update the GITHUB_REF.

For instance, in my case I start semantic-release in the workflow that is triggered by the workflow_run event and I explicitly checkout the repository main branch in it:

name: Build 
on:
  workflow_run:
    workflows:
      - Run tests
    types:
      - completed
      - 
jobs:
  BuildApp:
    name: Build application
    runs-on: ubuntu-latest
    outputs:
    steps:
      - name: Checkout repository
        uses: actions/checkout@v4
        with:
          fetch-depth: 0
          ref: ${{ github.event.workflow_run.head_branch }}
...

And in that case, GITHUB_REF points to the default repository branch (which is develop in my case), but I'm working with the main branch.

As we anyway in the environment that should have a git CLI, why not just get the current branch from the git branch output execution, if that is possible?

Environment:

• CI: Github

[travi]

i've suspected that there is an opportunity to improve the way this works for github actions, but havent had a chance to investigate far enough to understand alternatives. if you'd be willing to investigate far enough to provide detail of the alternatives available that we could use, that would really help the chances if this being improved.

also, could you share some detail of your use case? i've mostly approached supporting this package from the perspective of how it is used within semantic-release. if your use case is different than that, having a better idea of your goal would be helpful

[konclave]

Regarding the use case:
We're using Github. We have two branches: main and develop. Develop is the default branch is develop. We develop features in feature branches, create a PR to the develop branch, merge the feature after PR review with commit squash and using the PR title as a new commit comment. That's how we get the feature/bugfix/whatever development history following the conventional commit.

develop branch is deployed to the dev server every time something is pushed into it.

After the feature or set of features is tested, we merge the develop branch to the main branch. And this merge starts the release workflow.

Release workflow is started for main branch and is triggered with the test/lint/typecheck workflow, which runs on every push to main/develop branch.

As the workflow trigger is workflow_run, you can't rely on the GITHUB_REF value anymore. Workflow is started by the push to the main branch, but github checks out the default branch. In our case, it's develop, so, we have to check out the main branch explicitly. But GITHUB_REF still refers to the default develop branch and that leads to release skip by semantic-release even been started in the main branch.

At first, I assumed that in our case we can read the github file with the event data, is it is done for some of the cases, and refer to the workflow_run.head_branch there (because we check out this branch, as in our case it's what we need), but that won't work if you checkout some other branch. I can't image the specific workflow, but technically, it's possible. And in that case workflow_run.head_branch will refer to the branch where the event is happening, GITHUB_REF will refer to the default branch, and you will be at some third branch.

And the only reliable way of getting the branch that I see is reading in from the git binary execution. As we're anyway assuming that we are working in the environment that has a git binary, I don't see any obstacles why not to do that. But maybe I'm missing something.

If that approach is fine, I can make a PR.

[travi]

to be honest, i'm having a hard time understanding your workflow and you motivation for using it.

from what i do understand about what you describe, i dont think your concern is unique to the implementation of env-ci for a github action workflow. changing the branch to a different branch than what triggered the workflow is not a currently supported workflow for any of the ci services supported by env-ci.

you mention that you are using env-ci in the context of semantic-release, so i'll also highlight that the workflow you seem to be describing is not one that we would recommend using semantic-release with in the first place. semantic-release is intended to be triggered automatically when commits are pushed to a release branch. it seems like you are taking steps to make that process more manual, which is not really the intent of semantic-release.

i'm wondering if your problem would simply go away if you simplified your intended workflow to a more typical workflow supported by semantic-release

[konclave]

It is like that. I'm starting semantic-release on the push into the release branch. But the release branch is not the default branch of the repo and that affects the github environment variables values in the workflows.

But just not to have all-in-one workflow, I split it to two workflow. First starts on push, second (that actually runs the semantic-release) starts on the first workflow successful end.

And yes, it could be solved with moving everything in one workflow, but I don't see why that should be a mandatory for running semantic-release.

Anyway, my point is that GITHUB_REF doesn't actually reflect the proper branch name in the context of Github actions.
GITHUB_REF could have one branch name, while actually you're working on the other branch name.

[travi]

I'm starting semantic-release on the push into the release branch. But the release branch is not the default branch of the repo and that affects the github environment variables values in the workflows.

i still dont understand. being the default branch should not matter. actions workflows can be triggered by a push to any branch. i dont understand the need to switch branches with raw git after being triggered by a push to a different branch

[konclave]

The workflow that runs the semantic-release is not started by the push event directrly, it is started by the workflow_run event of the parent workflow, that was started by push:

Push to the release branch -> Test/typecheck Workflow run succeed -> Release workflow:

# first workflow that start on the push into the release branch (main in my case)
name: Run tests, linting and types checking
on:
  push:
    branches:
      - main

# second workflow, that depends on the first
name: Build, release and deploy
on:
  workflow_run:
    workflows:
      - Run tests, linting and types checking
    types:
      - completed

In that case, default branch setting matters, cause Release workflow is started against default branch, not the release branch.

Please, have a look on the documentation: https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflow_run and pay attention to the GITHUB_REF value part.

[travi]

Please, have a look on the documentation: docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflow_run and pay attention to the GITHUB_REF value pa

i'm familiar with triggering workflows with workflow_run, but it isnt clear to me why you would choose to use that approach for this situation over workflow_dispatch, which honors the trigger branch.

i've used that approach in the past to trigger semantic-release workflows and found it to be a successful approach without any need to checkout a different branch after the workflow was triggered. (i've personally moved away from that approach in favor of using a reusable workflow rather than triggering a completely separate workflow)

your chosen workflow seems unnecessarily complex when there are alternatives (worfklow_dispatch and reusable workflows) that should accomplish similar goals. if you think there is a need that is unfulfilled by the available alternatives, we would need to understand the gap very clearly before we would consider working around that complexity