Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

releases cannot be marked as prereleases #1077

Open
OdinValholl opened this issue Jan 30, 2025 · 4 comments
Open

releases cannot be marked as prereleases #1077

OdinValholl opened this issue Jan 30, 2025 · 4 comments
Labels
priority: p2 Moderately-important priority. Fix may not be included in next release. type: bug Error or flaw in code with unintended results or allowing sub-optimal usage patterns.

Comments

@OdinValholl
Copy link

OdinValholl commented Jan 30, 2025

Recently, releases can no longer be created as prereleases by setting the "prerelease": true configuration in the release-please-config.json file.

Can this issue currently be confirmed?

My release-please-config.json looks like this:

{
  "pull-request-title-pattern": "Release(${component}) v${version}",
  "prerelease": true,
  "include-v-in-tag": true,
  "include-component-in-tag": true,
  "tag-separator": "-",
  "separate-pull-requests": true,
  "component-no-space": true,
  "packages": {
    ".": {
      "package-name": "any-app",
      "component": "any-app",
      "release-type": "simple"
    }
  }
}

In addition, with this scheme I couldn't find out exactly at which level the prerelease-type can be set because it doesn't quite agree with the documentation in the README.

As further information, when setting up my project I noticed that the autoreleases could not be created because the corresponding labels for the pull requests were missing in the GitHub repository. I had to create these manually so that the release pull requests were labeled correctly. Could this also be a current bug?

Thanks a lot!

@OdinValholl OdinValholl added priority: p2 Moderately-important priority. Fix may not be included in next release. type: bug Error or flaw in code with unintended results or allowing sub-optimal usage patterns. labels Jan 30, 2025
@kallioaleksi
Copy link

I have the same issue, here's my config, it's slightly different:

{
  "packages": {
    ".": {
      "release-type": "node",
      "include-component-in-tag": false,
      "include-v-in-tag": true,
      "versioning": "prerelease",
      "prerelease": true,
      "prerelease-type": "beta",
      "changelog-path": "CHANGELOG.md",
      "bump-minor-pre-major": false,
      "bump-patch-for-minor-pre-major": false,
      "draft": false
    }
  },
  "$schema": "https://raw.githubusercontent.com/googleapis/release-please/main/schemas/config.json"
}

It creates the PR just fine, but doesn't mark it as a beta.

@OdinValholl
Copy link
Author

What I've found so far is that your manifest.json shouldn't be an empty JSON.
It should at least contain something like { ".": "0.1.0-beta0" } or something like that

@kallioaleksi
Copy link

I noticed that as well, the issue is that the repo will have two different workflows, betas from main to env/dev and actual releases from main to env/prod.

My manifest is

{
  ".": "1.0.0"
}

and the actual releases work just fine (e.g. 1.1.0), but the prerelease workflow creates actual releases as well, not 1.1.0-beta and 1.1.0-beta2 etc).

@OdinValholl
Copy link
Author

Yeah that's probably the only whay to trigger them seperately, or at least i couldn't find out yet how to do it in one workflow.

Do you seperate your manifest file for releases and prereleases?
And what happens if you set the config to "prerelease-type": "beta1" ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
priority: p2 Moderately-important priority. Fix may not be included in next release. type: bug Error or flaw in code with unintended results or allowing sub-optimal usage patterns.
Projects
None yet
Development

No branches or pull requests

2 participants