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.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Support specifying a component in "Relase-As:", empty commits monorepos #1905

Open
toddbaert opened this issue Apr 10, 2023 · 6 comments · May be fixed by #2031
Open

Support specifying a component in "Relase-As:", empty commits monorepos #1905

toddbaert opened this issue Apr 10, 2023 · 6 comments · May be fixed by #2031
Assignees
@chingor13
Labels
priority: p3 Desirable enhancement or fix. May not be included in next release. type: question Request for information or clarification. Not an issue.

Comments

@toddbaert
Copy link

toddbaert commented Apr 10, 2023 •
edited

It's convenient to be able to use an empty commit to specify a release version as described here. In the OpenFeature project, we have a number of monorepos that use release-please, and sometimes we want to create a release for a specific component in a monorepo without changes (releasing a 1.0 is a good example).

There doesn't seem to be a way to do this with an empty commit. Currently doing the above results in releasing all components at the specified version. It would be great if you could do something like add Component: my-library in the commit body to tell the manifest release which component you mean.

Apologies if this is already possible... I couldn't find doc about it.

I'd be interested in taking this on if there's agreement it's a reasonable addition.
@toddbaert toddbaert added priority: p3 Desirable enhancement or fix. May not be included in next release. type: question Request for information or clarification. Not an issue. labels Apr 10, 2023
@chingor13
Copy link
Contributor

The current usage for this is touch any file in that component's path (like a README or something). Then the Release-As commit will only apply to the component(s) touched in the commit.

@toddbaert
Copy link
Author

toddbaert commented Apr 10, 2023 •
edited

The current usage for this is touch any file in that component's path (like a README or something). Then the Release-As commit will only apply to the component(s) touched in the commit.

@chingor13

Ya, I'd like to avoid the touch, but this is a fine workaround and I understand if you'd not like to add code to support what I describe.

I hope it's not rude to point out this comment... that feature is far more important to us (in some ways this proposal is a stop-gap). 😅

@axieum
Copy link
Contributor

axieum commented Jul 30, 2023

I am happy to work on a PR for this change. How does this approach look?

chore: transition to beta

Component: foo
Component: baz
Release-As: 1.5.0-beta

This will cause the changelog to include the (originally hidden) "Miscellaneous Chores" section for those two components.

Is it possible "Component" could conflict with other headers?

axieum added a commit to axieum/release-please that referenced this issue Jul 30, 2023
@axieum
test: add failing tests for proposed 'Component' commit footer
8eb2495 
See googleapis#1905
@axieum axieum linked a pull request Jul 30, 2023 that will close this issue
Draft
4 tasks
@axieum
Copy link
Contributor

axieum commented Jul 30, 2023

I have added some failing tests in the above draft pull request. To make these pass, I believe we just need to check for the Component: ... commit footer during util.commit-split.CommitSplit#split() at this point:

release-please/src/util/commit-split.ts

Lines 111 to 113 in 5e67d02

// todo: handle 'Component: ...' commit footers
if (commit.files.length === 0 && this.includeEmpty) {
if (this.packagePaths) {

However, I noticed that the commit instance has not been parsed into a conventional commit (with notes, etc.), so we'd need to carefully apply regex over the raw commit message.

Does this sound right @chingor13? Or am I completely off track.

@jh-devv
Copy link

jh-devv commented Aug 30, 2023 •
edited

+1 This would be useful in one of my projects

@jh-devv jh-devv mentioned this issue Aug 30, 2023
Open
@axieum
Copy link
Contributor

axieum commented Oct 17, 2023

Workaround is to force a file change within the component, I noticed the {x-release-please-start-version} replacement block will replace any version, so you can just mock a change here and it'll immediately get replaced by the release-please PR.

image

Since the commit has a Release-As: footer, it will show up in the changelog. If you've already squashed the PR, just edit the PR description with the BEGIN_COMMIT_OVERRIDE to adjust the message as described in the project's readme.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@chingor13 chingor13

Labels
priority: p3 Desirable enhancement or fix. May not be included in next release. type: question Request for information or clarification. Not an issue.
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

feat: allow specifying components by Component commit footer axieum/release-please
4 participants
@chingor13 @axieum @toddbaert @jh-devv