feat(go): add support for releasing yoshi gapic go libraries #514
Conversation
google-cla
bot
added
the
cla: yes
Codecov Report
@@ Coverage Diff @@
## master #514 +/- ##
==========================================
+ Coverage 81.24% 81.66% +0.41%
==========================================
Files 41 42 +1
Lines 4815 4973 +158
Branches 407 400 -7
==========================================
+ Hits 3912 4061 +149
- Misses 902 911 +9
Partials 1 1
Continue to review full report at Codecov.
|
src/releasers/go-yoshi.ts
Outdated
|
|
||
| // These repos should be ignored when generating a release for the | ||
| // top level mono-repo: | ||
| const IGNORED_PATHS = [ |
There was a problem hiding this comment.
I'm ok with this for now, but ... I do wonder out loud what a more sustainable model for release-please looks like. I like the idea of built-in support for monorepo setups, and for split repo setups across languages. For cases where there is very customer configuration like this, I'd very much like to start thinking about a config format you could use so this code can remain more generalized. This isn't blocking feedback for this PR, just a seed to plant.
There was a problem hiding this comment.
I think we will eventually want this to be programatic, especially if we ever start split out into more and more sub-modules. But for now, this "works" for the top level module at least. I am still grokking what this code has context to. I have some ideas in the back of my head how we could make this better in the future. For now... 🤔
There was a problem hiding this comment.
so, we do have some support for mono-repos now:
But I was thinking this logic is a little yoshi specific...
What I've been thinking would be nice, would be to keep these yoshi specific strategies somewhat hidden, i.e., not calling them out in documentation. And, when we add a strategy like yoshi-java, or yoshi-go, it would be nice to also add corresponding strategies that are closer to something the community could use.
|
I think this is good enough for the core parent module imo. I am not sure what is up with the failing header check, snapshots should be exempts according to the config... @bcoe if you want to take a look again too, can't add you as a review since you opened the PR. |
|
@codyoss we should add an exception for the |
src/releasers/go-yoshi.ts
Outdated
| }); | ||
|
|
||
| // remove commit reference from auto-generate gapics | ||
| changelogEntry = changelogEntry.replace(/\s\(\[null\].*\n/, '\n'); |
There was a problem hiding this comment.
I find this logic a little bit weird, I'll take a look before I land and see if we can simplify.
|
@bcoe It looks like snapshots should already be ignored if I am understanding this right. release-please/.bots/header-checker-lint.json Lines 2 to 4 in a6c9e0b |
|
@codyoss weird, it's Should that ignore rule be |
|
@bcoe I rule looked right to me, and it works for all the other files in that directory. I think |
Once merged, we can merge the connected PR and then we should start to see proposed releases for the root module. More work will need to be done to figure out supporting the sub-modules. Related: googleapis/release-please#514
…#2716) Once merged, we can merge the connected PR and then we should start to see proposed releases for the root module. More work will need to be done to figure out supporting the sub-modules. Related: googleapis/release-please#514
This adds support for releasing the Yoshi gapic go libraries.
TODO:
Future Work:
CC: @codyoss