Skip to content

Commit

Permalink
ci: improve publish to use tags based on branch
Browse files Browse the repository at this point in the history
  • Loading branch information
mduenias committed Jun 12, 2023
1 parent 29a7ab4 commit f5bb190
Show file tree
Hide file tree
Showing 5 changed files with 25 additions and 9 deletions.
2 changes: 1 addition & 1 deletion .github/workflows/release.yml
Original file line number Diff line number Diff line change
Expand Up @@ -19,7 +19,7 @@ jobs:
publish_packages:
name: Publish Packages
needs: [ validations ]
if: github.ref == 'refs/heads/main' || github.ref == 'refs/heads/next' || github.ref == 'refs/heads/beta'
if: github.ref == 'refs/heads/main' || github.ref == 'refs/heads/beta'
uses: ./.github/workflows/publish.yml
with:
node_version: 16
Expand Down
17 changes: 11 additions & 6 deletions ADRs/003_Release_strategy.md
Original file line number Diff line number Diff line change
Expand Up @@ -4,6 +4,8 @@

Date: 28.03.2022

Updated: 12.06.2023

### Status

accepted
Expand Down Expand Up @@ -39,13 +41,16 @@ In the file release.config.js we can configure semantic-release to do the follow
5. Publish on our GitHub repo the [release notes](https://github.com/otto-ec/b2b-design-system/releases)
(@semantic-release/github)

### Development Options
### Release types

As we have released a stable version of the library, our release strategy works as follows:

- Any releases run from branch `main` will publish a stable version of the npm package with format `vx.x.x` and tag
`latest`.
- Any releases run from `beta` will publish a pre-release version of the npm package with format `vx.x.x-beta.n` and
tag `beta`. Where `n` will increase for any new beta release on that `x` version.

1. Until we reach base maturity in our product, we will release to branch beta, which will create releases in the
format `x.x.x-beta`. Once we have priority 1 components ready, we can merge beta to main and then just continue
with normal feature branches
2. Not using `beta` branch. We run the risk reaching early big release numbers as we could potentially be
making many breaking changes.
- Beta can be merged into `main` once this pre-release has been tested and approved. Then a new Release should be triggered from `main` to publish a stable release.

## Decision
We are using a GitHub workflow `release.yml` that is triggered manually from GH Actions ui, by choosing from
Expand Down
1 change: 0 additions & 1 deletion package.json
Original file line number Diff line number Diff line change
Expand Up @@ -14,7 +14,6 @@
"homepage": "https://github.com/otto-de/b2b-design-system#readme",
"scripts": {
"deploy": "npm run deploy --workspace=@otto-de/b2b-core-components",
"publish": "npm publish --workspace packages/",
"release": "semantic-release",
"build-tokens": "npm run build --workspace=@otto-de/b2b-tokens",
"build-core-components": "npm run build --workspace=@otto-de/b2b-core-components",
Expand Down
2 changes: 1 addition & 1 deletion release.config.js
Original file line number Diff line number Diff line change
Expand Up @@ -21,7 +21,7 @@ module.exports = {
[
'@semantic-release/exec',
{
"publishCmd": "npm run publish -- --tag=${branch.name}",
"publishCmd": "node ./scripts/publish.sh ${branch.name}",
}
],
[
Expand Down
12 changes: 12 additions & 0 deletions scripts/publish.sh
Original file line number Diff line number Diff line change
@@ -0,0 +1,12 @@
#! /usr/bin/env bash

branch="${1}"

tag=$branch
if [[ $branch = 'main' ]] || [[ ! -n $branch ]];
then
tag="latest"
fi

echo publishing on tag ${tag}
npm publish --workspace packages/ --tag=$tag

0 comments on commit f5bb190

Please sign in to comment.