[MINOR] release workflows corrected also added publish workflows

.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
+exclude-labels:
+  - 'skip-changelog'
+  - 'release:none'

.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

.github/workflows/release-drafter.yml

@@ -6,37 +6,70 @@ 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:
     permissions:
       # 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/[email protected]
-        # (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 }}
+          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 }}
+
+
+

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