Example use with a monorepo

[tjdavis3]

I am attempting to test with a simple monorepo with two projects. A vue.js frontend and a golang backend. I've attempted to setup an action for each along with the path. When I do not use the multirepo-tags: true option I get errors. However, when setting it to true there is never a PR created.

On a commit with a subject of: fix(frontend): Update the following output is received:

Run GoogleCloudPlatform/release-please-action@v2
  with:
    token: ***
    release-type: node
    path: frontend
    package-name: frontend
    monorepo-tags: true
    fork: false
    clean: true
    bump-minor-pre-major: false
    pull-request-title-pattern: chore${scope}: release${component} ${version}
✖ No merged release PR found
✖ Unable to build candidate
✖ pull #60 046444097948def303e3c556c6ce42470591b7bd has not yet been released

Is there an example of exactly how to use release-please with a monorepo and what exactly monorepo-tags does?

[bcoe]

@tjdavis3 two approaches you might consider, if you want to release the modules independently, I have an example of monorepo tags in action here -- The only thing we might need to dig into, is whether it works as expected with go.

An exciting new approach for managing monorepos, is what @joeldodge79 has been working on here, manifest based releasers. I'd be tempted to try out the latter.

[yliu-d]

I'm running into same issue. @bcoe your suggestions are about when to trigger release-please-action, but the issues we are facing is, after release-please is called, it find change, but does not create pr, here is the error message I'm getting:

Run GoogleCloudPlatform/[email protected]
  with:
    token: ***
    release-type: node
    package-name: playback-publish
    default-branch: hotfix-release-please
    monorepo-tags: true
    path: services/playback_publish
    fork: false
    clean: true
    bump-minor-pre-major: false
    pull-request-title-pattern: chore${scope}: release${component} ${version}
⚠ No merged release PR found
✖ Unable to build candidate
✔ found 39 commits since 17f2b07d78608787044393aefd30fb06340ba4d2
✔ release as patch: There are 0 BREAKING CHANGES and 0 features
⚠ no user facing commits found since 17f2b07d78608787044393aefd30fb06340ba4d2

[JakeChampion]

We have a monorepo using release-please-action here -> https:/Financial-Times/origami

It is working really well for us, thank you to all the people who worked on release-please and the action! <3

[kettanaito]

Thanks for sharing the example, @JakeChampion!

Please, I can see a difference in the if value in your release-please.yml workflow compared to what is suggested in the README:

The README:

 if: ${{ steps.release.outputs.release_created }}

Your example:

 if: ${{ steps.release.outputs.releases_created }}

Notice the "release_s_" (multiple).

Is there a particular difference between using release_created and releases_created?

[JakeChampion]

Is there a particular difference between using release_created and releases_created?

I don't know what the difference is, hopefully a release-please maintainer could answer that for you. What I do know, is our release process is working perfectly for us since we moved to using release-please and the release-please-action

[kettanaito]

I can suspect that releases_created is the right property in case you release multiple packages from a single repo (like in your example). Yeah, would be nice to get some clarification on that.

[kettanaito]

If anybody's struggling with proper release in a monorepo, note that you must use:

if: ${{ steps.release.outputs.releases_created }}

Notice "releases" not release_created as in the README.

Using release_created had no effect and is either a typo or applicable only when releasing a single package. Switching to releases_created now properly executes the following steps conditionally.

[mrchief]

@JakeChampion Thanks for sharing your example. I've a monorepo where:

• merge to main creates 1 or more release PRs (depending on packages)
• the release PRs publish a prerelease version to npm registry (private registry on github)
• on merging the release PR, it creates the github releases, tags and the final version in npm registry

Is your workflow similar?

@bcoe is this something release-please can do on its own (in conjunction with npm publish -w <workspace>? We're using lerna publish for now but I'd like to get rid of it as it involves some serious elbow grease for tagging and cutting releases.

[joeldodge79]

is the "elbow grease" manual or automated? in our sdk-codegen repo we end up with lots of tags and releases but release-please does it for us. then we use lerna publish to send everything to npmjs

• release-please workflow
• lerna publish workflow (note our use of Wombat Dressing Room that allows us to use the release-please generated releases/tags to "authorize" the publishing)

[mrchief]

It's bunch of extra bash commands to format tags as per lerna's liking and also create pre-release versions of packages. I checked origmai repo but I couldn't find any workflow that runs on release PR close, so I was wondering how you manage creating release PRs (at this point create pre-release versions of package), and closing release PRs (at this point create final version of package).

[mrchief]

Part of the complexity comes from the fact that main branch is protected, so we can't commit directly to it.

[joeldodge79]

In case it's relevant, we're on an old version of release-please-action (hopefully updating to latest in the next few months)

how you manage creating release PRs

using command: manifest sets up release-please to both create and update a release PR as well as create releases/tags when a human merges it

format tags as per lerna's liking

I don't have it all in my brain right now but we got it setup so that our lerna publish workflow (in conjunction with Wombat Dressing Room) is happy with the format of the tags that release-please creates

create pre-release versions of packages

We don't publish pre-release versions. However, I believe release-please has some support for setting pre-release versions in which case hopefully you could control that from either inputs to the action or from within the release-please-config.json and just use the regular workflow.

[mrchief]

using command: manifest sets up release-please to both create and update a release PR as well as create releases/tags when a human merges it

Ah, it makes sense now. In both cases (merging feature PR to main and release PR to main) will trigger release-please so you don't need a special pull_request: [closed] workflow.

I don't have it all in my brain right now but we got it setup so that our lerna publish workflow (in conjunction with Wombat Dressing Room) is happy with the format of the tags that release-please creates

In that case, I'll take a look again. I was thinking of ditching lerna publish altogether and use npm publish -w ... instead. release-please correctly calculates the next version anyway so not sure if I need lerna for anything else.

We don't publish pre-release versions. However, I believe release-please has some support for setting pre-release versions in which case hopefully you could control that from either inputs to the action or from within the release-please-config.json and just use the regular workflow.

I didn't see any support for pre-release versions to package registry (I saw draft and prerelease for github releases) but now that I understand how manifest works, I think I can tweak my processes to create pre-release packages (if I can't find anything with release-please first)

Thanks for your help!

[joeldodge79]

I'm not exactly sure how prerelease works but it looks like there's manifest support and hopefully you can ask around based on googleapis/release-please#1181

[mrchief]

I see. Looks like I can use the pre-release version to publish to package registry. I'll give it a try, thanks!

[mrchief]

So prerelease only works for premajor versions. For anything >1.0.0, it creates regular releases. The action doesn't provide paths_released when creating the release PR

{
  "pr": {"headBranchName":"release-please--branches--main","baseBranchName":"main","number":22,"title":"chore: release main","body":":robot: I have created a release *beep* *boop*\n---\n\n\n<details><summary>foo: 0.3.0</summary>\n\n## [0.3.0](https:/acme/monorepo/compare/foo-v0.2.0...foo-v0.3.0) (2022-02-24)\n\n\n### Features\n\n* new things ([9a371bd](https:/acme/monorepo/commit/9a371bdd48b4bf567143522efbba403aa28b9510))\n</details>\n\n<details><summary>bar: 1.2.0</summary>\n\n## [1.2.0](https:/acme/monorepo/compare/bar-v1.1.0...bar-v1.2.0) (2022-02-24)\n\n\n### Features\n\n* new things ([9a371bd](https:/acme/monorepo/commit/9a371bdd48b4bf567143522efbba403aa28b9510))\n</details>\n\n---\nThis PR was generated with [Release Please](https:/googleapis/release-please). See [documentation](https:/googleapis/release-please#release-please).","files":[],"labels":["autorelease: pending"]},
  "prs": [{"headBranchName":"release-please--branches--main","baseBranchName":"main","number":22,"title":"chore: release main","body":":robot: I have created a release *beep* *boop*\n---\n\n\n<details><summary>foo: 0.3.0</summary>\n\n## [0.3.0](https:/acme/monorepo/compare/foo-v0.2.0...foo-v0.3.0) (2022-02-24)\n\n\n### Features\n\n* new things ([9a371bd](https:/acme/monorepo/commit/9a371bdd48b4bf567143522efbba403aa28b9510))\n</details>\n\n<details><summary>bar: 1.2.0</summary>\n\n## [1.2.0](https:/acme/monorepo/compare/bar-v1.1.0...bar-v1.2.0) (2022-02-24)\n\n\n### Features\n\n* new things ([9a371bd](https:/acme/monorepo/commit/9a371bdd48b4bf567143522efbba403aa28b9510))\n</details>\n\n---\nThis PR was generated with [Release Please](https:/googleapis/release-please). See [documentation](https:/googleapis/release-please#release-please).","files":[],"labels":["autorelease: pending"]}],
  "paths_released": "[]"
}

Looks like I need to hack the summary and parse out <pkg>:<ver> to find out which packages are getting released. I'm trying to get this info so I can publish beta versions of the package to npm registry.