diff --git a/.github/release-drafter.yml b/.github/release-drafter.yml index 75c57c99..51bf0ff9 100644 --- a/.github/release-drafter.yml +++ b/.github/release-drafter.yml @@ -1,31 +1,46 @@ -name-template: 'v$RESOLVED_VERSION 🌈' +name-template: 'v$RESOLVED_VERSION' tag-template: 'v$RESOLVED_VERSION' categories: - - title: '🚀 Features' + - title: 'Features' labels: - 'feature' - 'enhancement' - - title: '🐛 Bug Fixes' + - title: 'Bug Fixes' labels: - 'fix' - 'bugfix' - 'bug' - - title: '🧰 Maintenance' - labels: 'chore' -change-template: '- $TITLE @$AUTHOR (#$NUMBER)' + - title: 'Maintenance' + labels: + - 'chore' + - 'dependencies' + - 'ci' + - 'refactor' +template: | + ## What's Changed + + $CHANGES + +change-template: '* $TITLE (#$NUMBER) @$AUTHOR' change-title-escapes: '\<*_&' # You can add # and @ to disable mentions, and add ` to disable code blocks. version-resolver: major: labels: - - 'major' + - 'release:major' + - 'major' # major in pr title minor: labels: + - 'release:minor' - 'minor' patch: labels: + - 'release:patch' - 'patch' + - 'fix' + - 'documentation' + - 'chore' default: patch -template: | - ## Changes - $CHANGES \ No newline at end of file +exclude-labels: + - 'skip-changelog' + - 'release:none' \ No newline at end of file diff --git a/.github/workflows/publish-to-chrome.yml b/.github/workflows/publish-to-chrome.yml new file mode 100644 index 00000000..fe99632e --- /dev/null +++ b/.github/workflows/publish-to-chrome.yml @@ -0,0 +1,28 @@ +name: Publish to Chrome Web Store + +on: + release: + types: [published] # triggers when a release is published manually + +jobs: + publish: + runs-on: ubuntu-latest + steps: + - name: Checkout code + uses: actions/checkout@v4 + with: + ref: ${{ github.ref_name }} + + - name: Create ZIP file + run: | + cd src + zip -r ../scrum-helper.zip . + + - name: Upload to Chrome Web Store + uses: PlasmoHQ/chrome-extension@v3 + with: + client_id: ${{ secrets.CHROME_CLIENT_ID }} + client_secret: ${{ secrets.CHROME_CLIENT_SECRET }} + refresh_token: ${{ secrets.CHROME_REFRESH_TOKEN }} + extension_id: ${{ secrets.CHROME_EXTENSION_ID }} + zip: scrum-helper.zip \ No newline at end of file diff --git a/.github/workflows/release-drafter.yml b/.github/workflows/release-drafter.yml index d84c395f..fcff0b31 100644 --- a/.github/workflows/release-drafter.yml +++ b/.github/workflows/release-drafter.yml @@ -6,16 +6,11 @@ on: branches: - master - # pull_request event is required only for autolabeler pull_request: - # Only following types are handled by the action, but one can default to all as well types: [opened, reopened, synchronize] - # pull_request_target event is required for autolabeler to support PRs from forks - # pull_request_target: - # types: [opened, reopened, synchronize] permissions: - contents: read + contents: write jobs: update_release_draft: @@ -23,20 +18,58 @@ jobs: # write permission is required to create a github release contents: write # write permission is required for autolabeler - # otherwise, read permission is required at least pull-requests: write runs-on: ubuntu-latest steps: - # (Optional) GitHub Enterprise requires GHE_HOST variable set - #- name: Set GHE_HOST - # run: | - # echo "GHE_HOST=${GITHUB_SERVER_URL##https:\/\/}" >> $GITHUB_ENV # Drafts your next Release notes as Pull Requests are merged into "master" - - uses: release-drafter/release-drafter@v6.1.0 - # (Optional) specify config name to use, relative to .github/. Default: release-drafter.yml - # with: - # config-name: my-config.yml - # disable-autolabeler: true + - name: Draft Release + id: release_drafter + uses: release-drafter/release-drafter@v6 + with: + config-name: release-drafter.yml + publish: true env: - GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} \ No newline at end of file + GITHUB_TOKEN: ${{secrets.GITHUB_TOKEN}} + + - name: Checkout code + uses: actions/checkout@v4 + with: + fetch-depth: 0 + + - name: Ensure correct branch is checked out (only on PR) + if: github.event_name == 'pull_request' + run: | + echo "Checking out PR source branch: ${{ github.head_ref }}" + git fetch origin ${{ github.head_ref }} + git checkout ${{ github.head_ref }} + + - name: Setup Node.js + uses: actions/setup-node@v4 + with: + node-version: '20' + + - name: Update Changelog + run: | + VERSION="${{ steps.release_drafter.outputs.tag_name }}" + BODY="${{ steps.release_drafter.outputs.body }}" + + # Create a new changelog entry file + echo -e "## ${VERSION} ($(date +'%Y-%m-%d'))\n\n${BODY}\n\n" > new_changelog_entry.md + + # Prepend the new entry to the existing CHANGELOG.md + if [ -f CHANGELOG.md ]; then + cat CHANGELOG.md >> new_changelog_entry.md + fi + mv new_changelog_entry.md CHANGELOG.md + + # Commits the updated CHANGELOG.md and creates a tag for the new version + - name: Commit and Push Changelog + uses: stefanzweifel/git-auto-commit-action@v5 + with: + commit_message: 'docs: Update CHANGELOG.md for ${{ steps.release_drafter.outputs.tag_name }}' + file_pattern: 'CHANGELOG.md' + tagging_message: ${{ steps.release_drafter.outputs.tag_name }} + + + \ No newline at end of file diff --git a/README.md b/README.md index df5f2ed5..460921ab 100644 --- a/README.md +++ b/README.md @@ -178,10 +178,64 @@ If you want to share your translation with others: For more details, see the [Chrome i18n documentation](https://developer.chrome.com/docs/extensions/reference/i18n/). +## Release Process + +This project uses a fully automated release process powered by GitHub Actions. Understanding this process is helpful for both maintainers and contributors. + +The process is split into two parts: + +### 1. Automated Release Drafting + +This part runs every time a pull request is merged into the `master` branch. + +1. **PR Merge**: A contributor's pull request is reviewed and merged. +2. **Drafting Workflow**: The "Release Drafter" workflow is triggered. +3. **Versioning**: The workflow inspects the `release:*` label or PR title to determine the next semantic version. +4. **Changelog Update**: The `CHANGELOG.md` file is automatically updated with the titles of the merged PRs. +5. **Draft Creation**: A new draft release is created or updated in the [Releases](https://github.com/fossasia/scrum-helper/releases) section. This draft includes the new version tag and the updated changelog notes. + +### 2. Manual Release Publishing + +This part is performed manually by maintainers when it's time to publish a new version. + +1. **Verification**: A maintainer reviews the draft release to ensure it's accurate and complete. +2. **Publishing**: The maintainer publishes the release from the GitHub UI. +3. **Chrome Web Store Deployment**: Publishing the release triggers the "Publish to Chrome Web Store" workflow, which automatically packages the extension and uploads it for review. + ## About contributing - Follow the Issues and PRs templates as far as possible. - If you want to make a PR, please mention in the corresponding issue that you are working on it. + +### Writing Meaningful Pull Requests + +The release notes are automatically generated from the pull requests merged into `master`. To ensure the release notes are clear and helpful, please: + +1. **Write a descriptive title.** The PR title is the primary entry in the release notes. It should concisely summarize the change. +2. **Provide a clear description.** The body of your PR should explain the "what" and "why" of your changes. This context is invaluable for reviewers and for anyone looking back at the project's history. + +### Pull Request Labeling & Semantic Versioning +This project uses an automated release process that relies on pull request labels and titles to determine the semantic version for a new release. For your contribution to be included in the release notes, please use one of the methods below. + +**Method 1: Using Labels (Preferred)** + +The clearest way to signal the impact of your change is to apply **one** of the following labels to your pull request. This is the recommended approach. + +- `release:major`: For breaking changes that are not backward-compatible. +- `release:minor`: For new features or significant enhancements. +- `release:patch`: For backward-compatible bug fixes, documentation updates, or maintenance. +- `release:none`: To exclude the change from the release notes entirely. + +**Method 2: Using PR Titles** + +As a fallback, if no `release:*` label is applied, the system will inspect your pull request title for the following keywords (case-insensitive) to determine the version bump: + +- `major`: For breaking changes. +- `minor`: For new features. +- `patch`, `fix`, `chore`, `documentation` : For bug fixes and other small changes. + +If you are unsure which label to use, please write a clear and descriptive title, and a maintainer will apply the correct label before merging. + - Before making a PR, ensure your code is properly formatted and linted: - Format your code: This command automatically formats your code based on the project's style guidelines. ```sh