chore(ci): update release-please to combine core packages into a single PR

[pearigee]

We are struggling with the conflicts created by merging individual release please PRs though updates to our global changelog.json.

We filed googleapis/release-please#2835 to resolve this permanently (by migrating to a changelog per package). However, in the mean time we will combine our core releases into a single PR to reduce toil.

This is also a blocker to our Node version upgrade as it will require many releases to complete.

[gemini-code-assist]

Code Review

This pull request splits the Release Please configuration by moving core packages from release-please-submodules.json into a new release-please-core.json file and updating .github/release-please.yml to run both configurations. The reviewer identified a critical issue where using the same manifest file (.release-please-manifest.json) for both configurations will cause Release Please to fail validation, and suggested splitting it into two separate manifest files.

[westarle]

How did you verify it works? Does release-please have a dry run?

[westarle]

I think the release please folks were happy with your suggestion to move core things to release-please-config.json

[pearigee]

After doing a bit of digging, I found this linked-versions plugin: https://github.com/googleapis/release-please/blob/main/src/plugins/linked-versions.ts

If I am understanding correctly, enabling this plugin would effectively group the core packages into a single PR AND augment the branch name to avoid a conflict?

It would look like this:

  "plugins": [
    {
      "type": "linked-versions",
      "groupName": "core",
      "components": [
        "common",
        "jsdoc-fresh",
        "jsdoc-region-tag",
        "pack-n-play",
        "gapic-generator",
        "gapic-node-processing",
        "google-gax",
        "gaxios",
        "gcp-metadata",
        "google-auth-library",
        "google-logging-utils",
        "googleapis-common",
        "google-proto-files",
        "proto3-json-serializer",
        "retry-request",
        "teeny-request",
        "gapic-tools",
        "typeless-sample-bot",
        "paginator",
        "precise-date",
        "projectify",
        "promisify"
      ]
    },
    {
      "type": "sentence-case"
    }
  ], 

If I am understanding the functionality correctly would result in a branch name of release-please--branches--main--groups--core and should avoid the conflict on release-please--branches--main.

[pearigee]

I ran the following command to verify my config:

npx release-please release-pr \
  --dry-run \
  --repo-url=googleapis/google-cloud-node \
  --target-branch=pearigee-release-please-core \
  --config-file=release-please-core.json \
  --manifest-file=.release-please-manifest.json \
  --local \
  --local-path=. \
  --token="$(gh auth token)"

Unfortunately, it revealed that this plugin (while it does create a separate branch), forces all packages to have the same version number. I now understand what "linked-versions" means here.

Not the right solution for us.

[pearigee]

As a temporary work around, I have moved the core libraries from release-please-submodules.json to release-please-config.json.

This will group librarian made package/* changes and handwritten core/* which is undesirable, but we don't appear to have a better short term option.

It looks like the publicly available release-please version (via npx release-please) doesn't include the node-librarian release type, so I had to build/run the command from source to verify:

node ~/Documents/release-please/build/src/bin/release-please.js release-pr \
  --dry-run \
  --repo-url=googleapis/google-cloud-node \
  --target-branch=pearigee-release-please-core \
  --config-file=release-please-config.json \
  --manifest-file=.release-please-manifest.json \
  --local \
  --local-path=. \
  --token="$(gh auth token)"

Command completes successfully and generates a single PR.