Attach release notes to `output.publishedPackages`

[lorenzomigliorero]

At the moment, output.publishedPackages only contains the new version/name of the pkgs.
It'd be nice having also the release notes attached, so for example a Slack notification can be triggered including the latest published changes.

  const release = await createRelease(octokit, {
    pkg,
    tagName: `v${pkg.packageJson.version}`,
  });

  ...

  if (releasedPackages.length) {
    return {
      published: true,
      publishedPackages: releasedPackages.map((pkg) => ({
        name: pkg.packageJson.name,
        version: pkg.packageJson.version,
+       notes: release.body
      })),
    };
  }

[Andarist]

The problem with that is that the release body might get truncated because there is some max length to it. In such a case we have to put some "stub text" into the release. What would you expect to get here? That stubbed release note? Or what got prepended to the CHANGELOG?

Also please note that the limit that I'm talking about is per release. Here, you are suggesting outputting the body of each release into a single JSON. This compounds the problem because we could run out of the available size (whatever that is for the action's output) way more easily.

Have you considered different solutions? This very action has some utilities to grab the recently generated content from CHANGELOG files - based on the available output you could write a script that would do the same thing, directly from CHANGELOG files. This way, it would be up to you to handle any potential limits that might be applicable to your use case.

[lorenzomigliorero]

The problem with that is that the release body might get truncated because there is some max length to it. In such a case we have to put some "stub text" into the release. What would you expect to get here? That stubbed release note? Or what got prepended to the CHANGELOG?

I can't follow here, sorry.
Do you mean that the octokit.createRelease fn can return the release.body truncated?

Also please note that the limit that I'm talking about is per release. Here, you are suggesting outputting the body of each release into a single JSON. This compounds the problem because we could run out of the available size (whatever that is for the action's output) way more easily.

Good point, I haven't thought about the action output limit.
The single output limit is about 1MB (50mb total), probably a reasonable length for the majority of cases?

Have you considered different solutions? This very action has some utilities to grab the recently generated content from CHANGELOG files - based on the available output you could write a script that would do the same thing, directly from CHANGELOG files. This way, it would be up to you to handle any potential limits that might be applicable to your use case.

Yeah, that's the alternative. Wondering if with a custom script I'll have the same problem.
Soon or later, the output will be shared with the action-slack-incoming-webhook, and will be subject to the same length limit.

[Andarist]

Do you mean that the octokit.createRelease fn can return the release.body truncated?

No. I mean that we might have to truncate the release.body that we pass to createRelease because we can't exceed its character limit.

The single output limit is about 1MB (50mb total), probably a reasonable length for the majority of cases?

That's what I thought at first about the PR's body limit 😅

Soon or later, the output will be shared with the action-slack-incoming-webhook, and will be subject to the same length limit.

Yeah, you are right - you might always end up hitting a character limit somewhere. But this proposed solution shifts the responsibility on you to handle that. This might sound like a chore but it's also more flexible - cause what if you actually want to grab full release notes and send them somewhere where there are no limits? If we'd truncate this thing on your behalf then you wouldn't be able to do this as easily as the context would already be truncated.

I think that we should either make it easy for you to grab this information with a script or introduce a way for us to dump this into a file (based on some input). If we'd go with the file-based option then you could just pick up the file in your next steps and process it however you'd like