Version calculation includes package-name as prefix as of v3.2.4

[tshowers-bt]

TL;DR

Existing projects are having their versions reset to 1.0.0 because the package-name is being included as a prefix when searching for the latest released version. I've left a comment on what I believe to be the offending code change.

Expected behavior

Projects whose workflows have not changed should continue to continue to calculate versions as they have with previous v3 versions.

Observed behavior

Projects are including package-name as a prefix when searching for the latest release version and therefore determining there have been no releases.

Action YAML

name: "Release Please Build"

on:
  push:
    branches: [master]

env:
  PACKAGE_NAME: Eventing.Kafka

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Setup Release Please
        uses: google-github-actions/release-please-action@v3
        id: release
        with:
          token: ${{ secrets.GITHUB_TOKEN }}
          release-type: simple
          package-name: ${{ env.PACKAGE_NAME }}

Log output

No response

Additional information

No response

[chingor13]

Please try with the latest upgraded version which should have fixed this.

[AllexVeldman]

Ran into the same thing with v3.2.5, removing the package-name made sure the branch created and the tag lookup was correct.

[ChristianTellefsen]

I tried removing package-name just now, but it still updated the wrong branch. Retrying using 3.2.3...

[ChristianTellefsen]

Using 3.2.3 works fine for me.

[chingor13]

The changes in the latest versions of release-please were around the branch name used. package-name should only be necessary to configure if you are using monorepo-tags (component prefix in the release tag).

@tshowers-bt Is your scenario working with the latest v3 (3.2.5)?

@ChristianTellefsen Can you add your config and the branch name of the last merged release pull request?

[tshowers-bt]

chingor13 I've pinned to 3.2.3 (everything works fine there), I'll try 3.2.5 shortly and let you know.

As a general recommendation should package-name be omitted for single-package repos? We have dozens of services/libraries and tend to use the same basic workflow so I've been adding it entirely because it was there in my "working examples". I'd call this a breaking change either way and hope 3.2.5 works without any updates to the workflows required, but in anticipation of an eventual v4 I'd remove the package-name anyway.

[ChristianTellefsen]

@ChristianTellefsen Can you add your config and the branch name of the last merged release pull request?

Which config do you mean?

[ChristianTellefsen]

We got an issue in one of our packages after all this. Not sure what is going on. As far as I can tell, the package version in package,json is not the same version as any released package. I cannot see from the logs which release it is actually trying to push.

12s
Run google-github-actions/[email protected]
✔ Looking for latest release on branch: main with prefix: 
✔ Building releases
✔ Building strategies by path
✔ Building release for path: .
⚠ Duplicate release tag: tagName
Error: release-please failed: Validation Failed: {"resource":"Release","code":"already_exists","field":"tag_name"}

[chingor13]

Which config do you mean?

The GitHub action config for release-please-action

⚠ Duplicate release tag: tagName

The action tries to tag release PRs. It seems it's finding a unreleased PR (labelled autorelease: pending) and the version it tries to tag already exists. You can unstick this by removing the autorelease: pending label (or changing it to autorelease: tagged). The question (and maybe bug) is how that duplicate release version pull request was created.

[tshowers-bt]

I seem to be getting the expected version with the latest v3 though the action output is still referring to looking for the latest release with a specific prefix

where previous action runs did not.

I have no stake in the log message but it seems odd for the bug to leave a vestige like that