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鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

createGithubReleases: true -> body is too long (max is 125000 characters) #304

Closed
sethidden opened this issue Jun 23, 2023 · 3 comments
Closed

Comments

@sethidden
Copy link

sethidden commented Jun 23, 2023

This is #174 but instead of PR descriptions it's about GitHUb release descriptions being too long when createGithubReleases is true

Click to expand

logs from changesets/action@v1
馃  warn ===============================IMPORTANT!===============================
馃  warn You are in prerelease mode so packages will be published to the rc
馃  warn         dist tag except for packages that have not had normal releases which will be published to latest
馃  warn ----------------------------------------------------------------------
馃  info npm info redacted-package-name
馃  info redacted-package-name is being published because our local version (2.5.0-rc.2) has not been published on npm
馃  info Publishing redacted-package-name at "2.5.0-rc.2"
馃  success packages published successfully:
馃  redacted-package-name
馃  Creating git tag...
馃  New tag:  redacted-package-name
Done in 24.45s.
/usr/bin/git push origin --tags
To https://github.com/REDACTED/REDACTED
 * [new tag]         [email protected] -> [email protected]
Deprecation: [@octokit/request-error] `error.code` is deprecated, use `error.status`.
    at RequestError.get (/home/runner/work/_actions/changesets/action/v1/dist/index.js:1:324267)
    at createRelease (/home/runner/work/_actions/changesets/action/v1/dist/index.js:59:78814)
    at async Promise.all (index 0)
    at async runPublish (/home/runner/work/_actions/changesets/action/v1/dist/index.js:59:79464)
    at async /home/runner/work/_actions/changesets/action/v1/dist/index.js:59:75689
Error: HttpError: Validation Failed: {"resource":"Release","code":"custom","field":"body","message":"body is too long (maximum is 125000 characters)"}
Error: Validation Failed: {"resource":"Release","code":"custom","field":"body","message":"body is too long (maximum is 125000 characters)"}

Indeed, my CHANGELOG.md is 231,000 and 609,000 lines long respectively (depends on which one you use :P), which is higher than the 125,000 limit imposed by GitHub.

I assume this is due to the fact that changesets/action created a release using the entire contents of CHANGELOG.md (which would have the changesets removed from repo and applied to changelog)? I guess it'd be possible to write some hacky regex to publish only the latest markdown headline, so it always shows only the latest version in the release.


This was actually discussed here as well #157 (comment)

I know this error was described as highly unlikely to happen in the above link, but it's legitimately happening to us. This is a 2 year old project that used to use the conventional commits PR generator, and the changelog is legitimately this large.

@sethidden sethidden changed the title body is too long (max is 125000 characters) createGithubReleases: true -> body is too long (max is 125000 characters) Jun 23, 2023
@Andarist
Copy link
Member

I assume this is due to the fact that changesets/action created a release using the entire contents of CHANGELOG.md

This is not supposed to happen - if it happens then it should be considered a bug.

I guess it'd be possible to write some hacky regex to publish only the latest markdown headline, so it always shows only the latest version in the release.

This is kinda what we do, IIRC. Could you recheck with the source code and your CHANGELOG.md what was sent with that request?

@sethidden
Copy link
Author

sethidden commented Jun 23, 2023

@Andarist OK I know why it's happening

The top level entry in the CHANGELOG for the package that I was releasing is:

# Change Log

## 2.5.0-rc.1

### Minor Changes

- some changes here

however, the changesets/action@v1 run that failed due to the "max 125000 characters" error was triggered by a commit to main which:

  • bumped the version from 2.5.0-rc.1 to 2.5.0-rc.2 (manually)
  • included no changesets at all, so the above version bump was again, manual, and the action went along to publish the package

This means that there is no changelog entry for the new manually changed 2.5.0-rc.2

The action is trying to push the whole CHANGELOG.md due to the implementation of getChangelogEntry.
It will return the whole changelog if the version argument in getChangelogEntry is asking to find a Changelog entry for a version that's not present in the changelog.

Here's a repro case where getChangelogEntry unexpectedly (?) returns the whole changelog:

const contents = `
# Change Log 

## 2.5.0-rc.2

### Minor Changes

- Changes from rc2

## 2.5.0-rc.1

### Minor Changes

- Changes from rc1
`

// rc.3 is not present in the changelog above, unlike rc.1 and rc.2
const versionThatDoesntExistInTheChangelog = '2.5.0-rc.3' 

console.log(getChangelogEntry(contents, versionThatDoesntExistInTheChangelog))
Output of console.log (click to expand)
{
  content: '# Change Log\n' +
    '\n' +
    '## 2.5.0-rc.2\n' +
    '\n' +
    '### Minor Changes\n' +
    '\n' +
    '-   Changes from rc2\n' +
    '\n' +
    '## 2.5.0-rc.1\n' +
    '\n' +
    '### Minor Changes\n' +
    '\n' +
    '-   Changes from rc1\n',
  highestLevel: 2
}

On one hand, I broke the repo (from changesets/action perspective) on my own wish due to the version bump commit to main, but on the other hand, I guess getChangelogEntry could hold the user's hand a bit more here. After all, the main problem here seems to be "you're trying to publish a package version for which there is no change log entry", and not "the changelog is too long". The current error message points the user to the latter, while the culprit is the former.

Perhaps a console.info saying "Can't find current package version in changelog, defaulting to whole changelog"?

Additionally, in the case above, the publish: script will be ran and the package will be published to the NPM registry correctly, but the GitHub release will fail.

sethidden added a commit to vuestorefront/integrations-github-workflows that referenced this issue Jun 23, 2023
WojtekTheWebDev added a commit to vuestorefront/integrations-github-workflows that referenced this issue Jul 13, 2023
* ci: build, lint and test on ci

* ci: add release action

* ci: cache coverage

* ci: use inputs for sonarcloud

* ci: use envs for inputs

* ci: use env for inputs

* ci: another try with inputs

* ci: fix syntax

* ci: add inputs

* refactor: clean blank lines

* ci: separate actions for sonarcloud

* ci: fix separate actions for sonarcloud

* ci: fix sonarcloud secrets

* ci: add project name

* ci: fix project name

* ci: add ci name

* ci: test structure

* ci: download artifacts to root

* ci: remove coverage

* ci: collect coverage from integration tests

* ci: prepare cd action

* ci: use main

* fix: input not required

* fix: use enterprise flag as input

* ci: remove publish script

* don't install husky git hooks when releasing

why would you do that? certain hooks like pre-commit (for the repos that
still use the stupid `commitizen`) the release will outright fail

* chore: don't use yarn built-in script because it doesn't shadow (#7)

* don't create github releases when publishing

changesets/action@v1 will try to create a GitHub release in the repo
when publishing a new package version.

changesets/action@v1 tries to publish the release
using the entire contents of the CHANGELOG.md as release description.
The changelog file is taken from the package
folder that it's publishing.

See here for the code: https://github.com/changesets/action/blob/main/src/run.ts#L66-L68

The max char limit of the release
description is 125,000 characters.

The problem is many of our packages actually have longer changelogs than
125,000.
For example this one has 200k characters: https://github.com/vuestorefront/bigcommerce/blob/main/packages/api-client/CHANGELOG.md

I admit Github releases would be very useful for e.g. registering the
Slack-Github bot in a customer's channel to let them now a new package
release had happened.

Unfortunately, I can't really remove the changelog because it contains
important historical information.

For now, I'm disabling creation of github releases and waiting for
changesets to implement truncation:
changesets/action#174 (comment)

* chore: add codeowners for PR notifications

* allow publishing OSS packages (#12)

* log in in open source packages too

in open source packages, we often publish to NPM. To do that, we need to
log in (so that changesets/actions know how to publish)

* publish using NPM_TOKEN if not enterprise

* re-enable creating gh releases

see changesets/action#304 (comment)

* stop linting pr title with conventional commits

we use changesets now so it's not necessary

* add abillity to inject environment variables for use by unified ci (#4)

* feat: allow setting env var

Sometimes, running `yarn test` can require env variables, e.g. in the
case of integration test

* ci: use alternative solution

---------

Co-authored-by: Wojciech Sikora <[email protected]>

* BREAKING don't log into private repo if it's not necessary

!! THIS WILL BREAK EXISTING REPOS !!

Before this commit, the repos running the CI action had no choice but
always log into our private NPM repo using NPM_USER and NPM_PASS secrets.
If you didn't have those secrets, the CI would fail.
The error that caused the failure was that "NPM_PASS" is not defined
as a secret. Of course it's not, because there's no reason to log in
to any NPM repository in a public package, since npmjs is public.

After this commit, the CI action doesn't log in into verdaccio by default.
For repos like magento2 which are public, and don't use private
pacakges, this doesn't make sense.

Especially now that we use NPM_RELEASE_TOKEN secret for
releases (which allows you to publish without having to provide
NPM_USER and NPM_PASS), passing NPM_USER and NPM_PASS for a public
repo makes even less sense.

---

The breaking change comes from the fact that in private GH repos where
the CI workflow is reused without explicitly passing the param "enterprise:
true" (it's not passed because this argument didn't exist before this commit),
will now default to "enterprise: false".

This will break our private GitHub repos that need to `npm install`
private vsf packages to work. It will break because the CI NPM will
not be logged in.

* remove unused ENVIRONMENT_VARIABLES input

I don't know how this got here, this is entirely unused

* remove unused sonarcloud vars

sonarcloud-related stuff lives in sonarcloud.yml now

* NPM_* secrets are used only if enterprise = true, so should be optional

* feat: add node versions matrix input

---------

Co-authored-by: Wojciech Sikora <[email protected]>
Co-authored-by: Artur Tagisow <[email protected]>
Co-authored-by: Wojciech Sikora <[email protected]>
Co-authored-by: Artur Tagisow <[email protected]>
Co-authored-by: John Doe <[email protected]>
@sethidden
Copy link
Author

sethidden commented Nov 9, 2023

Closing as stale. Workaround is described above.

sethidden added a commit to vuestorefront/vue-storefront that referenced this issue Apr 23, 2024
* ci: build, lint and test on ci

* ci: add release action

* ci: cache coverage

* ci: use inputs for sonarcloud

* ci: use envs for inputs

* ci: use env for inputs

* ci: another try with inputs

* ci: fix syntax

* ci: add inputs

* refactor: clean blank lines

* ci: separate actions for sonarcloud

* ci: fix separate actions for sonarcloud

* ci: fix sonarcloud secrets

* ci: add project name

* ci: fix project name

* ci: add ci name

* ci: test structure

* ci: download artifacts to root

* ci: remove coverage

* ci: collect coverage from integration tests

* ci: prepare cd action

* ci: use main

* fix: input not required

* fix: use enterprise flag as input

* ci: remove publish script

* don't install husky git hooks when releasing

why would you do that? certain hooks like pre-commit (for the repos that
still use the stupid `commitizen`) the release will outright fail

* chore: don't use yarn built-in script because it doesn't shadow (#7)

* don't create github releases when publishing

changesets/action@v1 will try to create a GitHub release in the repo
when publishing a new package version.

changesets/action@v1 tries to publish the release
using the entire contents of the CHANGELOG.md as release description.
The changelog file is taken from the package
folder that it's publishing.

See here for the code: https://github.com/changesets/action/blob/main/src/run.ts#L66-L68

The max char limit of the release
description is 125,000 characters.

The problem is many of our packages actually have longer changelogs than
125,000.
For example this one has 200k characters: https://github.com/vuestorefront/bigcommerce/blob/main/packages/api-client/CHANGELOG.md

I admit Github releases would be very useful for e.g. registering the
Slack-Github bot in a customer's channel to let them now a new package
release had happened.

Unfortunately, I can't really remove the changelog because it contains
important historical information.

For now, I'm disabling creation of github releases and waiting for
changesets to implement truncation:
changesets/action#174 (comment)

* chore: add codeowners for PR notifications

* allow publishing OSS packages (#12)

* log in in open source packages too

in open source packages, we often publish to NPM. To do that, we need to
log in (so that changesets/actions know how to publish)

* publish using NPM_TOKEN if not enterprise

* re-enable creating gh releases

see changesets/action#304 (comment)

* stop linting pr title with conventional commits

we use changesets now so it's not necessary

* add abillity to inject environment variables for use by unified ci (#4)

* feat: allow setting env var

Sometimes, running `yarn test` can require env variables, e.g. in the
case of integration test

* ci: use alternative solution

---------

Co-authored-by: Wojciech Sikora <[email protected]>

* BREAKING don't log into private repo if it's not necessary

!! THIS WILL BREAK EXISTING REPOS !!

Before this commit, the repos running the CI action had no choice but
always log into our private NPM repo using NPM_USER and NPM_PASS secrets.
If you didn't have those secrets, the CI would fail.
The error that caused the failure was that "NPM_PASS" is not defined
as a secret. Of course it's not, because there's no reason to log in
to any NPM repository in a public package, since npmjs is public.

After this commit, the CI action doesn't log in into verdaccio by default.
For repos like magento2 which are public, and don't use private
pacakges, this doesn't make sense.

Especially now that we use NPM_RELEASE_TOKEN secret for
releases (which allows you to publish without having to provide
NPM_USER and NPM_PASS), passing NPM_USER and NPM_PASS for a public
repo makes even less sense.

---

The breaking change comes from the fact that in private GH repos where
the CI workflow is reused without explicitly passing the param "enterprise:
true" (it's not passed because this argument didn't exist before this commit),
will now default to "enterprise: false".

This will break our private GitHub repos that need to `npm install`
private vsf packages to work. It will break because the CI NPM will
not be logged in.

* remove unused ENVIRONMENT_VARIABLES input

I don't know how this got here, this is entirely unused

* remove unused sonarcloud vars

sonarcloud-related stuff lives in sonarcloud.yml now

* NPM_* secrets are used only if enterprise = true, so should be optional

* feat: add node versions matrix input

---------

Co-authored-by: Wojciech Sikora <[email protected]>
Co-authored-by: Artur Tagisow <[email protected]>
Co-authored-by: Wojciech Sikora <[email protected]>
Co-authored-by: Artur Tagisow <[email protected]>
Co-authored-by: John Doe <[email protected]>
sethidden added a commit to vuestorefront/vue-storefront that referenced this issue Apr 23, 2024
* ci: build, lint and test on ci

* ci: add release action

* ci: cache coverage

* ci: use inputs for sonarcloud

* ci: use envs for inputs

* ci: use env for inputs

* ci: another try with inputs

* ci: fix syntax

* ci: add inputs

* refactor: clean blank lines

* ci: separate actions for sonarcloud

* ci: fix separate actions for sonarcloud

* ci: fix sonarcloud secrets

* ci: add project name

* ci: fix project name

* ci: add ci name

* ci: test structure

* ci: download artifacts to root

* ci: remove coverage

* ci: collect coverage from integration tests

* ci: prepare cd action

* ci: use main

* fix: input not required

* fix: use enterprise flag as input

* ci: remove publish script

* don't install husky git hooks when releasing

why would you do that? certain hooks like pre-commit (for the repos that
still use the stupid `commitizen`) the release will outright fail

* chore: don't use yarn built-in script because it doesn't shadow (#7)

* don't create github releases when publishing

changesets/action@v1 will try to create a GitHub release in the repo
when publishing a new package version.

changesets/action@v1 tries to publish the release
using the entire contents of the CHANGELOG.md as release description.
The changelog file is taken from the package
folder that it's publishing.

See here for the code: https://github.com/changesets/action/blob/main/src/run.ts#L66-L68

The max char limit of the release
description is 125,000 characters.

The problem is many of our packages actually have longer changelogs than
125,000.
For example this one has 200k characters: https://github.com/vuestorefront/bigcommerce/blob/main/packages/api-client/CHANGELOG.md

I admit Github releases would be very useful for e.g. registering the
Slack-Github bot in a customer's channel to let them now a new package
release had happened.

Unfortunately, I can't really remove the changelog because it contains
important historical information.

For now, I'm disabling creation of github releases and waiting for
changesets to implement truncation:
changesets/action#174 (comment)

* chore: add codeowners for PR notifications

* allow publishing OSS packages (#12)

* log in in open source packages too

in open source packages, we often publish to NPM. To do that, we need to
log in (so that changesets/actions know how to publish)

* publish using NPM_TOKEN if not enterprise

* re-enable creating gh releases

see changesets/action#304 (comment)

* stop linting pr title with conventional commits

we use changesets now so it's not necessary

* add abillity to inject environment variables for use by unified ci (#4)

* feat: allow setting env var

Sometimes, running `yarn test` can require env variables, e.g. in the
case of integration test

* ci: use alternative solution

---------

Co-authored-by: Wojciech Sikora <[email protected]>

* BREAKING don't log into private repo if it's not necessary

!! THIS WILL BREAK EXISTING REPOS !!

Before this commit, the repos running the CI action had no choice but
always log into our private NPM repo using NPM_USER and NPM_PASS secrets.
If you didn't have those secrets, the CI would fail.
The error that caused the failure was that "NPM_PASS" is not defined
as a secret. Of course it's not, because there's no reason to log in
to any NPM repository in a public package, since npmjs is public.

After this commit, the CI action doesn't log in into verdaccio by default.
For repos like magento2 which are public, and don't use private
pacakges, this doesn't make sense.

Especially now that we use NPM_RELEASE_TOKEN secret for
releases (which allows you to publish without having to provide
NPM_USER and NPM_PASS), passing NPM_USER and NPM_PASS for a public
repo makes even less sense.

---

The breaking change comes from the fact that in private GH repos where
the CI workflow is reused without explicitly passing the param "enterprise:
true" (it's not passed because this argument didn't exist before this commit),
will now default to "enterprise: false".

This will break our private GitHub repos that need to `npm install`
private vsf packages to work. It will break because the CI NPM will
not be logged in.

* remove unused ENVIRONMENT_VARIABLES input

I don't know how this got here, this is entirely unused

* remove unused sonarcloud vars

sonarcloud-related stuff lives in sonarcloud.yml now

* NPM_* secrets are used only if enterprise = true, so should be optional

* feat: add node versions matrix input

---------

Co-authored-by: Wojciech Sikora <[email protected]>
Co-authored-by: Artur Tagisow <[email protected]>
Co-authored-by: Wojciech Sikora <[email protected]>
Co-authored-by: Artur Tagisow <[email protected]>
Co-authored-by: John Doe <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants