feat: add generate-release-notes parameter

[fernandrone]

Add a parameter that sets the "generate_release_notes" boolean option of the API call. When set, it autogenerates a release note.

The parameter defaults to "false" so this is not a breaking change. See documentation on https://docs.github.com/en/rest/releases/releases?apiVersion=2022-11-28#create-a-release

[fernandrone]

FWIW I've tested this on my organization's internal repositories and it works as expected 👍🏻

[jvalecillos]

This should be part of this plugin, there's no reason for having the setting parameter but not having the config option for it.

[fernandrone]

FWIW I've found this version which supports it https://codeberg.org/woodpecker-plugins/release/src/branch/main/docs.md (and is likely to be compatible with drone, haven't tested it yet).

[jvalecillos]

FWIW I've found this version which supports it https://codeberg.org/woodpecker-plugins/release/src/branch/main/docs.md (and is likely to be compatible with drone, haven't tested it yet).

@fernandrone Could you please elaborate?

I tested it, and it actually doesn't work because, in that plugin, the setting is not set in the metadata. Therefore, it is never passed and is assumed to be false when calling the GitHub API. Not to mention, it is not a drop-in replacement because the other plugin requires some configuration shenanigans.

https://codeberg.org/woodpecker-plugins/release/src/branch/main/impl.go#L119-L130

	m := &forge.Metadata{
		Owner:      p.Metadata.Repository.Owner,
		Repo:       p.Metadata.Repository.Name,
		Tag:        strings.TrimPrefix(p.Metadata.Commit.Ref, "refs/tags/"),
		Target:     p.Settings.Target,
		Draft:      p.Settings.Draft,
		Prerelease: p.Settings.PreRelease,
		FileExists: p.Settings.FileExists,
		Title:      p.Settings.Title,
		Note:       p.Settings.Note,
		Overwrite:  p.Settings.Overwrite,
	}

[pitr]

I would also love to have this merged. Github's auto-generate release notes work well, and re-implementing this behaviour does not make sense.

The build shows up as failing, but I cannot access the details. Is there anything that could speed up the merge?

[jvalecillos]

@pitr The CI failed on this PR because the pipeline step for the linter uses golangci-lint with latest (instead of an specific version) and something may have changed in a newer version that is incompatible with the current source code or a dependency (I think that's the case).

We could create another PR fixing both problems, updating dependencies and whatnot. The question is whether or not the maintainers will merge it.