Wrong commit selection

[MaximeLaurenty]

Github Sentry Action Release Bug Report

This is a followup of https://github.com/getsentry/action-release/issues/139 given @andreiborza's last comment and given the issue persists.

Environment

How do you use this action? Standard Github runners, container built on top of archlinux:base

Which version of the action? getsentry/[email protected]

Steps to Reproduce

1. Setup action in our CI, triggered on every commit to master

      - name: Create Sentry release
        uses: getsentry/action-release@fa247637f74d407f51d8423a5dc10abae1917873 # v3.1.0 # https://github.com/getsentry/action-release/tags
        env:
          SENTRY_AUTH_TOKEN: ${{ secrets.SENTRY_AUTH_TOKEN }}
          SENTRY_ORG: ${{ vars.SENTRY_ORG }}
        with:
          environment: prod
          projects: js-angular spindjango php-symfony
          sourcemaps: web
          release: ${{ github.sha }}
          dist: ${{ github.sha }}
          url_prefix: "~"

2. Make multiples commits to master
3. Check info about releases into Sentry

Expected Result

Have only 1 commit in every release.

Actual Result

Most of the time, commits are properly set within releases (just 1), but sometimes a discrepancy happens and a release contains multiple commits (for which releases already exist): see here commits in the latest release (including previous bd4b346):

see here the release just before (which includes bd4b346 and only it):

links to sentry if you have access: erroneous release, right release before that & list of our releases logs with actions debugging enabled (after obfuscation of RUNS_ON related information + removed most of the frontend files): GHA_logs_sentry.txt

[andreiborza]

Hi @MaximeLaurenty, thanks for filing this as a new issue.

Have you found possible patterns for when this might happen? For example, does this happen if commits to master are quickly one after another?

[MaximeLaurenty]

After re-looking trough it, I found a pattern: sentry releases are using the full sha but we use a short sha in our backend code, so sentry creates new releases (for the backend projects but not for the frontend projects) for the short sha as soon as a request is spotted.

• When a release is created with the CLI / CI after a release created with the CLI / CI it's working fine,
• When a release is created with the CLI / CI after a release created with the short sha (which includes no commit), the issue happens and the release has a history of 20 commits.

After aligning releases & frontend code to use the short sha, this issue is not present anymore.

~~However another issue happens: source-map un-minification is not working anymore ... but I guess that's another topic.~~

[MaximeLaurenty]

@andreiborza Merging in our private repo a PR mentioning this issue closed it (I guess that's a github weird behaviour)

I'm not sure the issue should be closed though: the inference of commits when creating a release could be based on the latest 5-10 releases instead of just the last one.

[RomeoAva]

Hi,

I am also facing this same issue. I just started using Sentry and wanted to connect this action to my private Github project.

In my project the action is triggered in twice:

• Once when PR is merged onto main for the development environment.
• Once when main is released for the production environment.

Here is my workflow:

name: Sentry Release

on:
  workflow_call:
    inputs:
      environment:
        required: true
        type: string
        description: development | production

jobs:
  sentry:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: Create Sentry release
        uses: getsentry/action-release@v3
        env:
          SENTRY_AUTH_TOKEN: ${{ secrets.SENTRY_AUTH_TOKEN }}
          SENTRY_ORG: ${{ secrets.SENTRY_ORG }}
          SENTRY_PROJECT: ${{ secrets.SENTRY_PROJECT }}
        with:
          environment: ${{ inputs.environment }}
          release: ${{ github.sha }}
          dist: ${{ github.sha }}

But the issue is every time a release happens (no matter if its dev/prod), the Sentry UI is displaying the same Commits & Files Changed from previous releases.

I am not sure if I am doing something wrong..

Latest release:

The one before:

And same for the previous ones (won't screenshot every single one)

And realistically, between those releases only 1 file/commit was changed.

Also to note compared to this original issue, my application is solely backend (FastAPI App).

Thank you

[RomeoAva]

I think the issue might be caused by:

       with:
          fetch-depth: 0

I am following the documentation: https://github.com/getsentry/action-release?tab=readme-ov-file#usage

Edit: Nevermind it seems to still be happening even when removed.

[panthony]

Using action-release@v3 I have the same problem. Always 20 commits even when there are only 1 or 2 expected.

The flow is triggered when a tag is published only:

on:
  push:
    tags:
      - '*'

Using like this:

      - name: Create Sentry Release
        uses: getsentry/action-release@v3
        env:
          SENTRY_ORG: xx
          SENTRY_PROJECT: xx
          SENTRY_AUTH_TOKEN: xx
        with:
          environment: production
          release: ${{ env.APP_VERSION }}
          sourcemaps: dist/production

[andreiborza]

Hi, thank you for reporting this and sorry for the silence. I haven't been able to reproduce this yet and it fell off my radar after that. I'll take another stab at this next week.

[panthony]

No pressure, in my case because it's triggered on a published tag it is run in a context where it checked out the tag.

Seeing: https://github.com/getsentry/sentry-cli/blob/master/src/commands/releases/set_commits.rs#L190

I understand where the consistent 20 commits come from, the problem likely come from sentry-cli and not action-release.

--

I have a project where I do not have the issue that uses the same flow (PR @ release-please, publication on tag creation, ...), but it's not using this github action:

on:
  push:
    branches:
      - '**'
    tags:
      - '*'


    - name: Create a Sentry.io release
      uses: tclindner/[email protected]
      if: ${{ env.GIT_TAG_NAME }}
      env:
        SENTRY_AUTH_TOKEN: xxx
        SENTRY_ORG: xxx
        SENTRY_PROJECT: xxx
      with:
        tagName: ${{ env.GIT_TAG_NAME }}
        environment: prod

It was setup a long time ago, maybe before an official github actions was created.

It uses sentry CLI 1.2.0:

/home/runner/work/_actions/tclindner/sentry-releases-action/v1.2.0/dist/sentry-cli

[rocklan]

I have the same issue, and I think the problem is due to the way github/git tags releases. If you use the command git tag --contains SHA it shows all of the tags that contain the commit, as an example - https://stackoverflow.com/questions/59308676/multiple-git-tags-appear-in-software-release-on-github . Sentry isn't filtering the commits down to the first tag where the commit was added, but instead is showing all.

[trevorkwhite]

Worth noting that #287 will fix this because it can be specified manually

[andreiborza]

Since 3.4.0 it is now possible to manually set the commit range:

- uses: getsentry/action-release@v3
  with:
    set_commits: manual
    repo: your-org/your-repo
    commit: ${{ github.sha }}
    previous_commit: <previous_commit_sha>

[trevorkwhite]

@andreiborza one quick interesting note - if I specify the release along with the commit/previous commit it doesn't seem to actually be respected (I just see the commit sha). Is this a bug?

[andreiborza]

@trevorkwhite yea that sounds like a bug. I'll investigate tomorrow, thanks for raising it!