Skip to content
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

chore(repo): add release workflow action #51

Merged
merged 3 commits into from
May 10, 2024
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
67 changes: 67 additions & 0 deletions .github/workflows/nx-cloud-workflow-release.yml
Original file line number Diff line number Diff line change
@@ -0,0 +1,67 @@
name: Nx Cloud Workflow Release

permissions:
contents: write

on:
workflow_dispatch:
inputs:
commit:
description: 'Commit SHA(s) to cherry-pick'
required: false
version:
description: 'Version number for branch and tag'
required: true

jobs:
release:
runs-on: ubuntu-latest
steps:
- name: Checkout repository
uses: actions/checkout@v4
with:
fetch-depth: 0

- run: |
echo "# Nx Cloud Workflows Release" >> $GITHUB_STEP_SUMMARY
git config user.name "github-actions[bot]"
git config user.email "41898282+github-actions[bot]@users.noreply.github.com"
git fetch --all

- name: Create or checkout branch
run: |
MAJOR_VERSION=$(echo ${{ github.event.inputs.version }} | cut -d. -f1)
if git show-ref --verify --quiet refs/remotes/origin/releases/v$MAJOR_VERSION; then
git checkout releases/v$MAJOR_VERSION
else
git checkout -b releases/v$MAJOR_VERSION
fi

- name: Cherry-pick commits
run: |
IFS=',' read -ra COMMITS <<< "${{ github.event.inputs.commit }}"
for i in "${COMMITS[@]}"; do
git cherry-pick $i
done
if: ${{ github.event.inputs.commit }}

- name: Push changes
run: |
MAJOR_VERSION=$(echo ${{ github.event.inputs.version }} | cut -d. -f1)
git push origin releases/v$MAJOR_VERSION
echo "releases/v$MAJOR_VERSION updated" >> $GITHUB_STEP_SUMMARY

- name: Create or update tags
run: |
IFS='.' read -ra VERSIONS <<< "${{ github.event.inputs.version }}"
TAG=""
for i in "${VERSIONS[@]}"; do
if [ -z "$TAG" ]; then
TAG="$i"
else
TAG="$TAG.$i"
fi
git tag -f v$TAG
git push -f origin v$TAG
echo "v$TAG created :rocket:" >> $GITHUB_STEP_SUMMARY
done
27 changes: 24 additions & 3 deletions README.md
Original file line number Diff line number Diff line change
@@ -1,10 +1,31 @@
# NxCloud Workflows
# Nx Cloud Workflows

## Re-usable workflow step

1. Create your custom step in `workflow-steps/`
2. Build everything: `nx run-many -t build`
3. Commit everything
1. Important: The generated `dist/` files need to be checked in as well
4. Tag with a new version: `git tag v1.0`
5. Push your changes
4. Push your changes

## Process for Releasing New Versions

To release a new version, you'll need to run the [ Nx Cloud Workflow Release workflow ](https://github.com/nrwl/nx-cloud-workflows/actions/workflows/nx-cloud-workflow-release.yml). You would do this by providing the workflow with comma-separated commits that need cherry-picking, and the version you wish to release.

> [!NOTE]
> If a new release is required, you only need to provide the version number. This is because the workflow is designed to automatically create the branch and tag from the `main` HEAD if the new version is a major one. In contrast, for minor or patch versions, the latest HEAD on the related major branch is used based on the version number.

Below is a summary of what the workflow does:

- For every major release, a `releases/v*` branch is created
- The HEAD of each release branch will always have a major `v*` tag pointing to the HEAD of the branch
- Multiple tags could be created for branches needing minor/patch releases
- Here's how it works:
- For a 4.1 release, `v4` and `v4.1` tags are created at the HEAD of the release branch
- For a 4.2 release, `v4` and `v4.2` tags are created at the HEAD of the release branch, and the previous `v4.1` tag continues to exist
- For a 4.2.1 release, `v4`, `v4.2`, and `v4.2.1` tags are created at the HEAD
- Therefore, users can use `v4` to get all **_minor_** and **_patches_** automatically, or
- Use `v4.1` to get all **_patches_** automatically

> [!IMPORTANT]
> Always create tags off the release branches, and not directly on `main`. This allows the flexibility to work on `main` without unwarranted disruptions to users.