|
| 1 | +# Publishing SDKs |
| 2 | + |
| 3 | +Publishing a new SDK package in this monorepo typically happens in 2 |
| 4 | +phases: initial package publishing phase and stable release phase. |
| 5 | + |
| 6 | +> [!NOTE] |
| 7 | +> If you are moving an existing package to this monorepo, you should |
| 8 | +> still read through the [initial publishing](#initial-package-publishing) |
| 9 | +> and follow the relevant steps to initialize the CI implementation. |
| 10 | +
|
| 11 | +## Initial Package Publishing |
| 12 | + |
| 13 | +When publishing a package for the first time, developers must complete several steps not part of a typical package release. This phase is |
| 14 | +designed to: |
| 15 | + 1. Establish the CI implementation for the new package |
| 16 | + 2. Generate pre-release builds for testing |
| 17 | + |
| 18 | +### Step 1. Extend `release-please-config.json` |
| 19 | + |
| 20 | +When doing the initial release, you will need to add a new record to |
| 21 | +[`release-please-config.json`](../release-please-config.json): |
| 22 | +``` |
| 23 | +"packages/type/my-package": { |
| 24 | + "bump-minor-pre-major": true, |
| 25 | + "release-as": "0.1.0", |
| 26 | + "bootstrap-sha": "MY_SHA" |
| 27 | +} |
| 28 | +``` |
| 29 | +> [!TIP] |
| 30 | +> `bump-minor-pre-major` only needs to be set if you are publishing |
| 31 | +> unstable releases (major version `0`). This option ensures that |
| 32 | +> breaking changes will only increment minor version. |
| 33 | +
|
| 34 | +> [!TIP] |
| 35 | +> `bootstrap-sha` will ensure that the conventional commits are |
| 36 | +> calculated from a certain point and not the whole package history. |
| 37 | +> You can find the appropriate commit sha using `git log`. |
| 38 | +
|
| 39 | +## 2. Add initial release manifest |
| 40 | + |
| 41 | +Add the following to `.release-please-manifest.json` |
| 42 | +``` |
| 43 | +"packages/type/my-package": "0.0.0" |
| 44 | +``` |
| 45 | + |
| 46 | +## 3. Add option to manual workflows |
| 47 | + |
| 48 | +Add `PATH_TO_YOUR_PACKAGE` to the `on.workflow_dispatch.inputs.workspace_path.options` |
| 49 | +array in the following files: |
| 50 | +- [`manual-publish-docs.yml`](../.github/workflows/manual-publish-docs.yml) |
| 51 | +- [`manual-publish.yml`](../.github/workflows/manual-publish.yml) |
| 52 | + |
| 53 | +## 4. Create a CI non-release workflow for just the project |
| 54 | + |
| 55 | +You will add a file in the `.github/workflows` directory that tells GHA (mostly) how to |
| 56 | +test your SDK. Below is a simple template to get started: |
| 57 | +``` |
| 58 | +name: sdk/YOUR_SDK |
| 59 | +
|
| 60 | +on: |
| 61 | + push: |
| 62 | + branches: [main, 'feat/**'] |
| 63 | + paths-ignore: |
| 64 | + - '**.md' |
| 65 | + pull_request: |
| 66 | + branches: [main, 'feat/**'] |
| 67 | + paths-ignore: |
| 68 | + - '**.md' |
| 69 | +
|
| 70 | +jobs: |
| 71 | + build-test-YOUR_SDK: |
| 72 | + runs-on: ubuntu-latest |
| 73 | + steps: |
| 74 | + - uses: actions/checkout@v4 |
| 75 | + - uses: actions/setup-node@v4 |
| 76 | + with: |
| 77 | + node-version: lts/* |
| 78 | + registry-url: 'https://registry.npmjs.org' |
| 79 | + - id: shared |
| 80 | + name: Shared CI Steps |
| 81 | + uses: ./actions/ci |
| 82 | + with: |
| 83 | + workspace_name: YOUR_PACKAGE_NAME |
| 84 | + workspace_path: PATH_TO_YOUR_PACKAGE |
| 85 | +``` |
| 86 | +> ![TIP] |
| 87 | +> you should test your configuration on [your local machine](../.github/CI_CONTRIBUTING.md) if |
| 88 | +> possible. |
| 89 | +
|
| 90 | +<!-- TODO document the stable release phase ---> |
0 commit comments