Closed rsenden closed 11 months ago
The core release-please library supports monorepos where you configure multiple "components" that are released and tagged independently. You will need to configure a "manifest configuration" to use this.
Additionally, we have the notion of plugins which can modify the release PRs after they are assembled and the most common use case is a "workspace plugin" which bumps internal dependency versions within a monorepo. So if A depends on B and B has a new version, we will also bump A's version and reference the new B version. We don't have a workspace plugin for knowing how GitHub action components in a monorepo are structured yet (would take a feature PR if this is a common setup in the community).
TL;DR
Allow for easily customizing the contents of the release PR.
Detailed design
We're developing a single GitHub Action repository that contains multiple (composite) actions that need to be versioned together. For example, when invoking
org/github-action@v1.0.0
, this composite action should invoke the correspondingorg/github-action/sub-action@v1.0.0
. Unfortunately, GitHub doesn't seem to support such use cases out of the box, so when releasing a new version of our action repository, all composite actions need to be updated to use the properorg/github-action/<sub-action>@<version>
.Ideally, probably not directly related to release-please-action, individual branches should automatically use
org/github-action/<sub-action>@main
ororg/github-action/<sub-action>@feat-1
, if the calling workflow is referring to an action branch instead of release version.Unless you have any better suggestions, the best way to accomplish this seems to be to have a workflow that updates the composite action.yml files on branches and in release PRs generated by release-please-action. As a proof of concept, I've come up with the following:
update-action-refs.sh
script used by the workflow below:GitHub Actions workflow
Based on some limited testing, this workflow seems to work fine, but improvement suggestions are welcome.
Some release-please-action improvement suggestions:
release-type: simple
to generate a version.txt file that we can use to determine the appropriate version number of the next release; the workflow would require modifications if we require any other release type. Ideally, when generating a release PR, release-please-action should expose the same version outputs as when merging a release PR, likemajor
,minor
,patch
andversion
.fromJSON
method, it would be easier if release-please-action would output PR properties as individual properties instead of JSON object, for example allowing to use${{steps.release_please.outputs.pr.headBranchName}}
.Additional information
See https://github.com/orgs/community/discussions/75505 for more information on this topic.