|
| 1 | +# Release Please Workflow |
| 2 | + |
| 3 | +This document explains the automated release and publishing workflow for the UI5 CLI monorepo using [Release Please](https://github.com/googleapis/release-please). |
| 4 | + |
| 5 | +## Table of Contents |
| 6 | + |
| 7 | +- [Overview](#overview) |
| 8 | +- [Workflow Architecture](#workflow-architecture) |
| 9 | +- [Release Please Configuration](#release-please-configuration) |
| 10 | + |
| 11 | +## Overview |
| 12 | + |
| 13 | +UI5 CLI uses an automated release workflow powered by Release Please to perform the following tasks: |
| 14 | +1. **Automatically generate release PRs** based on Conventional Commits |
| 15 | +2. **Update version numbers** across all workspace packages synchronously |
| 16 | +3. **Generate changelogs** for each package |
| 17 | +4. **Publish packages to npm** sequentially to respect dependency order |
| 18 | +5. **Create GitHub releases** with release notes |
| 19 | + |
| 20 | +## Workflow Architecture |
| 21 | + |
| 22 | + |
| 23 | + |
| 24 | +The workflow consists of three main jobs: |
| 25 | + |
| 26 | +### 1. `release-please` Job |
| 27 | +- **Trigger**: Push to `main` branch |
| 28 | +- **Purpose**: Creates/updates version bumps and changelogs for all of the packages in a single PR. |
| 29 | + |
| 30 | +### 2. `publish-packages` Job |
| 31 | +- **Trigger**: Merge of release PR into `main` branch |
| 32 | +- **Action**: Developer merges the release PR in GitHub |
| 33 | +- **Result**: |
| 34 | + - Release Please creates separate releases & tags in GitHub for every package |
| 35 | + - Packages are published to NPM sequentially (logger → fs → builder → server → project) |
| 36 | +- **Strategy**: Sequential execution (`max-parallel: 1`) to ensure dependencies exist before dependents |
| 37 | + |
| 38 | +### 3. `publish-cli` Job |
| 39 | +- **Trigger**: All other packages have been published |
| 40 | +- **Purpose**: Generates `npm-shrinkwrap.json` using `shrinkwrap-extractor` and publishes the CLI package |
| 41 | +- **Why separate**: The shrinkwrap must contain published registry versions of workspace packages, not workspace links. This requires all dependencies to be available on npm registry first. |
| 42 | +- **How it works**: The `shrinkwrap-extractor` reads the monorepo's `package-lock.json`, extracts production dependencies for `@ui5/cli`, converts workspace references to registry URLs, and generates a valid `npm-shrinkwrap.json` that will be included in the published CLI package. |
| 43 | + |
| 44 | +## Release Please Configuration |
| 45 | + |
| 46 | +The configuration is defined in [`release-please-config.json`](../release-please-config.json). This section explains our specific configuration choices and constraints. |
| 47 | + |
| 48 | +### Key Configuration Decisions |
| 49 | + |
| 50 | +#### PR Title Pattern |
| 51 | + |
| 52 | +```json |
| 53 | +"group-pull-request-title-pattern": "release: UI5 CLI packages ${branch}" |
| 54 | +``` |
| 55 | + |
| 56 | +**Why we can't use `${version}`**: When using the `linked-versions` plugin, Release Please doesn't support the `${version}` placeholder in the PR title pattern when creating single PR with multiple packages. In such case release please does not have a single source of truth even though packages are released under the same version. |
| 57 | +Adding the root package, will resolve this, but it will pollute the release notes with unnecessary information that we need to manually remove. |
| 58 | + |
| 59 | +**Documentation**: [group-pull-request-title-pattern](https://github.com/googleapis/release-please?tab=readme-ov-file#group-pull-request-title-pattern) |
| 60 | + |
| 61 | +--- |
| 62 | + |
| 63 | +#### Prerelease Configuration |
| 64 | + |
| 65 | +```json |
| 66 | +"prerelease": true, |
| 67 | +"prerelease-type": "alpha", |
| 68 | +"release-as": "5.0.0-alpha.0" |
| 69 | +``` |
| 70 | + |
| 71 | +**Purpose**: We're currently in alpha phase for v5.0.0. Once stable, these flags should be removed to enable normal semantic versioning. |
| 72 | + |
| 73 | +--- |
| 74 | + |
| 75 | +#### Package Configuration |
| 76 | + |
| 77 | +```json |
| 78 | +"packages": { |
| 79 | + "packages/logger": { "component": "logger" }, |
| 80 | + "packages/cli": { |
| 81 | + "component": "cli" |
| 82 | + } |
| 83 | +} |
| 84 | +``` |
| 85 | + |
| 86 | +**Why explicit package configuration**: We explicitly list packages rather than using `exclude-paths` to: |
| 87 | +1. Make it clear which packages are released |
| 88 | +2. Prevent accidental inclusion of internal tooling |
| 89 | +3. Keep the configuration maintainable |
| 90 | + |
| 91 | +**Why `"component"` doesn't include `@ui5` scope**: Using scoped names (e.g., `"@ui5/logger"`) in the component field can cause incorrect GitHub tagging behavior. |
| 92 | + |
| 93 | + |
| 94 | +--- |
| 95 | + |
| 96 | +#### Plugin Configuration |
| 97 | + |
| 98 | +**`node-workspace` with `merge: false`**: When using `linked-versions`, the `node-workspace` plugin **must** set `merge: false` ([documented requirement](https://github.com/googleapis/release-please/blob/main/docs/manifest-releaser.md#linked-versions)). This prevents conflicts in Release Please's internal manifest processing between: |
| 99 | +1. The `linked-versions` plugin synchronizing versions across all packages |
| 100 | +2. The `node-workspace` plugin updating workspace dependency references |
| 101 | + |
| 102 | +Without this flag, Release Please may fail to generate the release PR or produce incorrect version updates. |
| 103 | + |
| 104 | +**Note**: Release Please always force-pushes to the PR branch, so this flag only affects internal manifest processing, not Git commit structure. |
| 105 | + |
| 106 | +**`linked-versions`**: All UI5 CLI packages will be released together with synchronized version numbers. |
| 107 | + |
| 108 | +**Known limitations**: |
| 109 | +- Cannot resolve circular peer dependencies (e.g., `@ui5/project` ↔ `@ui5/builder`) |
| 110 | +- May update lockfile entries for npm aliases incorrectly |
| 111 | + |
| 112 | +**Workaround**: We manually update circular peer dependencies in the workflow after Release Please runs. |
| 113 | + |
| 114 | +--- |
| 115 | + |
| 116 | +#### Changelog Sections |
| 117 | + |
| 118 | +```json |
| 119 | +"changelog-sections": [ |
| 120 | + { "type": "feat", "section": "Features" }, |
| 121 | + { "type": "fix", "section": "Bug Fixes" }, |
| 122 | + { "type": "docs", "section": "Documentation", "hidden": true } |
| 123 | +] |
| 124 | +``` |
| 125 | + |
| 126 | +**Visible in changelogs**: Features, bug fixes, performance improvements, dependencies, reverts |
| 127 | + |
| 128 | +**Hidden but tracked**: Documentation, styles, refactoring, tests, build, CI, release |
| 129 | + |
| 130 | +**Rationale**: Internal changes don't need to appear in user-facing changelogs, but should still be tracked in commit history. |
| 131 | + |
0 commit comments