docs: adds commit guidelines #419
Conversation
|
| - **Body**: Optional, lists specific changes (e.g., `- add geopoint.xml demo form`). | ||
| - **Footer**: Use `Co-authored-by: @<username>` or `BREAKING CHANGE:` for automation. | ||
|
|
||
| Our commit message format enables automated release management. This standard ensures commits are categorized to trigger appropriate version bumps: |
There was a problem hiding this comment.
All of this is managed by changeset so this section doesn't feel relevant. Changeset makes sense in our context because the version bumps aren't always the same across packages.
There was a problem hiding this comment.
Do you see a benefit in having a format for commit messages?
There was a problem hiding this comment.
I find that prefixes make the commit history easier to understand and scan visually. But I may be biased from using them for years
There was a problem hiding this comment.
It would be interesting to tag and publish the packages when the prep PR is merged, based on a commit:
release: pack version and publish
There was a problem hiding this comment.
Note to myself - try this out later:
name: Tag packages for release
on:
pull_request:
types: [closed]
branches:
- main
jobs:
tag-packages:
if: github.event.pull_request.merged == true
runs-on: ubuntu-latest
steps:
# Checkout the repository with full history
- name: Checkout code
uses: actions/checkout@v4
with:
fetch-depth: 0
# Use a Personal Access Token to push tags (required for protected branches)
token: ${{ secrets.PAT }}
- name: Set up Node.js
uses: actions/setup-node@v4
with:
node-version: '20'
- name: Check commit message
id: check_commit
run: |
COMMIT_MESSAGE=$(git log --pretty=%B -1 ${{ github.event.pull_request.merge_commit_sha }})
echo "Commit message: $COMMIT_MESSAGE"
if echo "$COMMIT_MESSAGE" | grep -q "^release:"; then
echo "Release commit detected"
echo "is_release=true" >> $GITHUB_OUTPUT
else
echo "No release commit detected"
echo "is_release=false" >> $GITHUB_OUTPUT
fi
- name: Configure git
if: steps.check_commit.outputs.is_release == 'true'
run: |
git config user.name "github-actions[bot]"
git config user.email "github-actions[bot]@users.noreply.github.com"
- name: Tag packages
if: steps.check_commit.outputs.is_release == 'true'
run: |
# Array of package directories
PACKAGES=(
"packages/web-forms"
"packages/xforms-engine"
"packages/xpath"
"packages/tree-sitter-xpath"
)
for PKG in "${PACKAGES[@]}"; do
NAME=$(node -p "require('./$PKG/package.json').name")
VERSION=$(node -p "require('./$PKG/package.json').version")
TAG="$NAME@$VERSION"
if git tag | grep -Fx "$TAG"; then
echo "Tag $TAG already exists, skipping..."
else
echo "Creating tag $TAG for $NAME"
git tag "$TAG"
fi
done
# Push all new tags
git push origin --tags
There was a problem hiding this comment.
I don't mind the prefixes and happy to follow your lead there as long as we keep changeset for versioning and changelog management for now. I like the future idea of automating tag and release!
I have verified this PR works in these browsers (latest versions):
What else has been done to verify that this works as intended?
NA
Why is this the best possible solution? Were any other approaches considered?
NA
How does this change affect users? Describe intentional changes to behavior and behavior that could have accidentally been affected by code changes. In other words, what are the regression risks?
NA
Do we need any specific form for testing your changes? If so, please attach one.
NA
What's changed