-
Notifications
You must be signed in to change notification settings - Fork 76
ci(release-please): Release please single PR #1176
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.
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
base: main
Are you sure you want to change the base?
Changes from 19 commits
cc47ddc
c4a8080
b0f6de9
1d538cf
336eec3
3113d05
cb44e81
d5c901e
e1a17d2
bf4e402
81e3bc6
f5ac61b
d4b8f4c
3f35fe1
c182049
e6bba15
d67b4a5
24f2e73
f63a6c1
77d044e
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change | ||
|---|---|---|---|---|
| @@ -0,0 +1,95 @@ | ||||
| name: Release Please | ||||
|
|
||||
| on: | ||||
| push: | ||||
| branches: | ||||
| - main | ||||
|
|
||||
| permissions: | ||||
| contents: write | ||||
| pull-requests: write | ||||
| id-token: write # Required for trusted publishing via OIDC (https://docs.npmjs.com/trusted-publishers) | ||||
|
|
||||
| jobs: | ||||
| release-please: | ||||
| runs-on: ubuntu-24.04 | ||||
| steps: | ||||
| - uses: actions/checkout@v5 | ||||
|
|
||||
| - name: Node.js LTS | ||||
| uses: actions/setup-node@v5 | ||||
| with: | ||||
| node-version: 24.x | ||||
|
|
||||
| - name: Run Release Please to update PRs and create releases | ||||
| uses: googleapis/release-please-action@v4 | ||||
| id: release | ||||
| with: | ||||
| token: "${{ secrets.GITHUB_TOKEN }}" | ||||
|
|
||||
| publish-packages: | ||||
| runs-on: ubuntu-24.04 | ||||
| needs: release-please | ||||
| if: needs.release-please.outputs.releases_created == 'true' | ||||
| strategy: | ||||
| # Publish packages in dependency order: logger → fs → builder → server → project | ||||
| # CLI is handled separately to update shrinkwrap | ||||
| # Order of packages in the matrix does matter and is important! | ||||
| # release-please updates the package.json dependencies with ones that do not exist yet on NPM | ||||
| # Publish in the correct order is important, so that dependencies are available and resolved properly! | ||||
| max-parallel: 1 | ||||
| matrix: | ||||
| package: [logger, fs, builder, server, project] | ||||
| steps: | ||||
| - uses: actions/checkout@v5 | ||||
|
|
||||
| - name: Node.js LTS | ||||
| uses: actions/setup-node@v5 | ||||
| with: | ||||
| node-version: 24.x | ||||
|
|
||||
| - name: Install and publish ${{ matrix.package }} | ||||
| working-directory: packages/${{ matrix.package }} | ||||
| run: | | ||||
| echo "🚀 Publishing @ui5/${{ matrix.package }}" | ||||
|
|
||||
| # TODO: Uncomment when ready to publish | ||||
| # npm ci | ||||
| # npm publish --access public | ||||
d3xter666 marked this conversation as resolved.
Show resolved
Hide resolved
|
||||
|
|
||||
| publish-cli: | ||||
| runs-on: ubuntu-24.04 | ||||
| needs: [release-please, publish-packages] | ||||
| if: needs.release-please.outputs.releases_created == 'true' | ||||
| steps: | ||||
| - uses: actions/checkout@v5 | ||||
|
|
||||
| - name: Node.js LTS | ||||
| uses: actions/setup-node@v5 | ||||
| with: | ||||
| node-version: 24.x | ||||
|
|
||||
|
|
||||
| - name: Prepare production dependency tree | ||||
| working-directory: packages/cli | ||||
| run: | | ||||
| echo "📦 Installing production dependencies for CLI" | ||||
| npm ci --omit=dev | ||||
| - name: Generate npm-shrinkwrap.json (prod only) | ||||
|
||||
| "version": "4.3.0", |
I'm very unhappy about the missing support from npm for such a scenario, but I don't see that we should use such a setup as it defeats the purpose of using a lockfile in the project. We will end up shipping a release with dependency version combinations that were never tested before. If there happens to be no solution to this problem, I would rather prefer to stop using a shrinkwrap, as it would at least allow consumers to upgrade the transitive packages on their end if issues occur. But not using a shrinkwrap for CLI packages is IMHO not a good idea at all and I would really like to continue using it.
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,8 @@ | ||
| { | ||
| "packages/logger": "4.0.2", | ||
d3xter666 marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| "packages/fs": "4.0.2", | ||
| "packages/builder": "4.0.11", | ||
| "packages/server": "4.0.7", | ||
| "packages/project": "4.0.6", | ||
| "packages/cli": "4.0.26" | ||
| } | ||
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Special handling for the CLI package is required, where the shrinkwrap needs to be updated/created after all dependencies have been released. Should this be done in a separate PR?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks!
I think we had something related to the shrinkwrap itself, but I can't find the discussion/BLI!
I have updated the action so that it:
npm cifor publishing for the next package in the chain, it will have the previous package already published on NPM.As per my research this is the approach many monorepos are wokring. Lerna, for example