googleapis / release-please-action

automated releases based on conventional commits
Apache License 2.0
1.71k stars 212 forks source link

Add manifest file attributes as action output(s) #865

Open dschach opened 1 year ago

dschach commented 1 year ago

TL;DR

To help with using this workflow as an input to another job, I want to know some of the inputs on the way out, even if I'm using a manifest. At a minimum, please output the path, which would correspond to the entry in .release-please-manifest.json that is involved in this release.

Detailed design

My use-case is to use the path value to find an item in sfdx-project.json for Salesforce package development, and then to use values from that. If I have multiple packages being developed in one repo (our version of a monorepo) then each time RPAction runs, it should know which path in the manifest is being run, and should add that to its outputs.

The main goal here is to make an action that is analogous to uploading a package to npm, but for Salesforce. It will require adding a line to sfdx-project.json and editing some files, so I hope that any commit I make after RPAction but before that workflow finishes will be included in the same transaction.

Additional information

I think this is a great tool, and I'm trying to standardize a way to make it easier to upload package versions for Salesforce - as easy as it is to make a new npm package version.

Some of my beginnings of my work are at https://github.com/dschach/packaging-action-test where I'm starting with a single-package repo and then will make a multi-package... which may require a pull-request on release-please, but I don't want to get ahead of myself.

chingor13 commented 11 months ago

When the action creates releases, it does output a paths_released output (an array of string paths that were created). There are then path-based outputs: https://github.com/google-github-actions/release-please-action/tree/main#path-outputs

Are there additional outputs that are needed?

dschach commented 11 months ago

An example would be the changelog-path for the package (from the manifest) so I can do a string replace if a release is created.

The scenario is that after a release PR is merged (or during it, if possible), I want to create a new Salesforce package version and I want to update a specific README file, which is in the same directory as the changelog for a given package in a monorepo.