ci(release-please): Release please single PR

[d3xter666]

JIRA: CPOUI5FOUNDATION-1142
JIRA: CPOUI5FOUNDATION-1164

This change modifies several things, so the whole workflow can be complete:

• Creates a Release Please process
  • Adds release please configuration and pipeline
  • Releases the all of the package at once with a single PR
  • Generates an npm-shrinkwrap.json for the CLI package before being released (out of monorepo's root package-lock.json)
• Introduce a new package shrinkwrap-extractor to deal with @ui5/cli's npm-shrinkwrap.json generation in a monorepository environment
• Clear separation between "public" and "internal" packages
• Adjusts pipelines to deal with the new structure:
  • github-ci.yml
  • reuse-compliance.yml
• Adjust deploy-vitepress-docs.yaml so that it will generate API documentation out of published NPM packages and not from the packages within the monorepo
• Align package.json scripts, so that they can be easily (re)used within the monorepo structure.

[d3xter666]

Please find a sample result of this flow in here: https://github.com/d3xter666/ui5-tooling/pull/139

Note: Please ignore the title, it has been updated later in the config

[matz3]

Please see my comment here: https://github.com/d3xter666/ui5-tooling/pull/139#issuecomment-3473211965

[RandomByte]

For the shrinkwrap tool, I was wondering how we best integrate it in the monorepo. Maybe similar to the documentation as a dedicated package? Not sure whether lib/ is the best choice, since it's not really that important for the UI5/cli project.

[matz3]

My points have been addressed, but the comment by @RandomByte might still be open?

[d3xter666]

For the shrinkwrap tool, I was wondering how we best integrate it in the monorepo. Maybe similar to the documentation as a dedicated package? Not sure whether lib/ is the best choice, since it's not really that important for the UI5/cli project.

I don't have strong oppinion on how to handle this one. Here's the reasoning why it felt to me the right way to go:

• The documentation package is "self contained" (except maybe for the CLI.md generation) and felt naturally to do it in a separarte package
• The shrinkwrap tool has the @ui5/cli package "dependency" and the package-lock.json from the monorepo. So, I was wondering whether it's best to be part of any of those "packages". And as we want to ship the @ui5/cli as clean as possible, the natural choice was to go in the lib/ folder of the monorepo.

I'm curious to hear your oppinion on that.
If we decide now we'll pave the way for constant future structure of the monorepo

[RandomByte]

My understanding is that the shrinkwrap tool does not have a "dependency" to @ui5/cli. In fact, you can use it to extract the dependencies for any package from any given package-lock.json. We could even publish it as a dedicated tool, since other mono-repositories face similar problems.

Personally, I find it unconventional to put a helper tool into the root lib/ directory. In the UI5 linter project for example, lib/ contains the transpiled code of the linter: https://www.npmjs.com/package/@ui5/linter?activeTab=code

I would vote for putting it into a package similar to documentation.

[coveralls]

coverage: 94.885% (+0.01%) from 94.871%
when pulling 0ef9aae on feat-rp-single-pr
into ce96601 on main.

[coveralls]

coverage: 94.885% (+0.01%) from 94.871%
when pulling 0ef9aae on feat-rp-single-pr
into ce96601 on main.

[coveralls]

coverage: 94.885% (+0.01%) from 94.871%
when pulling 0ef9aae on feat-rp-single-pr
into ce96601 on main.

[coveralls]

coverage: 94.975% (+0.2%) from 94.811%
when pulling b03b5f6 on feat-rp-single-pr
into 78d312b on main.

[coveralls]

coverage: 94.885% (+0.01%) from 94.871%
when pulling 0ef9aae on feat-rp-single-pr
into ce96601 on main.

[coveralls]

coverage: 94.885% (+0.01%) from 94.871%
when pulling 0ef9aae on feat-rp-single-pr
into ce96601 on main.

[d3xter666]

• The shrinkwrap tool has the @ui5/cli package "dependency" and the package-lock.json from the monorepo. So, I was wondering whether it's best to be part of any of those "packages". And as we want to ship the @ui5/cli as clean as possible, the natural choice was to go in the lib/ folder of the monorepo.

Now, the shrinkwrap-extractor is a package within the packages folder. All the pipelines are adjusted, so that tests and integrations of the shrinkwrap-extractor are also executed

[matz3]

LGTM otherwise

[matz3]

... and this line are basically saying the same, isn't it?

[d3xter666]

I have reworded it. Thanks!

[RandomByte]

LGTM