.github/workflows/release-drafter.yml

@@ -15,6 +15,6 @@ jobs:
       contents: write
 
     steps:
-      - uses: release-drafter/release-drafter@v7
+      - uses: release-drafter/release-drafter@v6
         env:
           GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

CODE_OF_CONDUCT.md

@@ -72,4 +72,5 @@ available at https://www.contributor-covenant.org/version/1/4/code-of-conduct.ht
 
 [homepage]: https://www.contributor-covenant.org
 
-For answers to common questions about this code of conduct, see the [Contributor Covenant FAQ](https://www.contributor-covenant.org/faq).
+For answers to common questions about this code of conduct, see
+https://www.contributor-covenant.org/faq

EXAMPLES.md

@@ -1,551 +0,0 @@
-# Examples
-
-This document shows real-world scenarios where `git-auto-commit` is useful, with a working GitHub Actions workflow for each. The scenarios are based on questions and use cases that have come up in the [issues](https://github.com/stefanzweifel/git-auto-commit-action/issues) and [discussions](https://github.com/stefanzweifel/git-auto-commit-action/discussions) of this repository over the years.
-
-If you have a use case that isn't covered here, [open a discussion](https://github.com/stefanzweifel/git-auto-commit-action/discussions) — we may add it.
-
-## Table of Contents
-
-- [Auto-format code on pull requests](#auto-format-code-on-pull-requests)
-- [Auto-fix lint errors](#auto-fix-lint-errors)
-- [Update dependency lock files](#update-dependency-lock-files)
-- [Build and commit compiled assets](#build-and-commit-compiled-assets)
-- [Auto-generate API documentation](#auto-generate-api-documentation)
-- [Update README with generated content](#update-readme-with-generated-content)
-- [Maintain a CHANGELOG](#maintain-a-changelog)
-- [Sync translations / i18n files](#sync-translations--i18n-files)
-- [Publish a static site to a separate branch](#publish-a-static-site-to-a-separate-branch)
-- [Scheduled data refresh](#scheduled-data-refresh)
-- [Create a release tag without a commit](#create-a-release-tag-without-a-commit)
-- [Fail the build instead of pushing changes (drift check)](#fail-the-build-instead-of-pushing-changes-drift-check)
-- [Sign automated commits with GPG](#sign-automated-commits-with-gpg)
-- [Squash automated changes into the previous commit](#squash-automated-changes-into-the-previous-commit)
-
----
-
-## Auto-format code on pull requests
-
-**Description:** Run a code formatter (Prettier, php-cs-fixer, Black, gofmt, rustfmt, …) on every pull request and commit the resulting changes back to the contributor's branch. Contributors don't have to think about style; the bot fixes it for them.
-
-This is the most common use case for this Action. Running it on `pull_request` means the formatter only touches the PR branch — never your default branch directly.
-
-```yaml
-name: Format
-
-on: pull_request
-
-jobs:
-  prettier:
-    runs-on: ubuntu-latest
-    permissions:
-      contents: write
-
-    steps:
-      - uses: actions/checkout@v5
-        with:
-          ref: ${{ github.head_ref }}
-
-      - uses: actions/setup-node@v4
-        with:
-          node-version: 20
-
-      - run: npx prettier --write .
-
-      - uses: stefanzweifel/git-auto-commit-action@v7
-        with:
-          commit_message: "style: apply prettier formatting"
-```
-
-> [!TIP]
-> If the PR comes from a fork, the Action can only push back if the contributor enabled "Allow edits by maintainers". See the [forks section in the README](README.md#use-in-forks-from-public-repositories) for details.
-
----
-
-## Auto-fix lint errors
-
-**Description:** Many linters can both report and auto-fix problems (`eslint --fix`, `rubocop -a`, `ruff --fix`, `stylelint --fix`, …). Use the Action to commit the auto-fixed result so reviewers only see the issues that need human judgement.
-
-```yaml
-name: Lint and fix
-
-on: pull_request
-
-jobs:
-  eslint:
-    runs-on: ubuntu-latest
-    permissions:
-      contents: write
-
-    steps:
-      - uses: actions/checkout@v5
-        with:
-          ref: ${{ github.head_ref }}
-
-      - uses: actions/setup-node@v4
-        with:
-          node-version: 20
-          cache: npm
-
-      - run: npm ci
-      - run: npx eslint . --fix
-
-      - uses: stefanzweifel/git-auto-commit-action@v7
-        with:
-          commit_message: "chore: apply eslint --fix"
-```
-
-> [!TIP]
-> `file_pattern` is intentionally omitted here. If one of several custom patterns does not match a file in the repository, `git add` can fail with a pathspec error. Let the linter decide which files to change, or use a custom pattern that you know exists in your repository.
-
----
-
-## Update dependency lock files
-
-**Description:** When a dependency tool produces a fresh lock file (`package-lock.json`, `composer.lock`, `Gemfile.lock`, `poetry.lock`, …), commit only the lock file. Pair this with a scheduled job to keep lock files in sync without manual intervention.
-
-```yaml
-name: Refresh lock file
-
-on:
-  schedule:
-    - cron: "0 6 * * 1" # every Monday at 06:00 UTC
-  workflow_dispatch:
-
-jobs:
-  refresh:
-    runs-on: ubuntu-latest
-    permissions:
-      contents: write
-
-    steps:
-      - uses: actions/checkout@v5
-
-      - uses: actions/setup-node@v4
-        with:
-          node-version: 20
-
-      - run: npm install --package-lock-only
-
-      - uses: stefanzweifel/git-auto-commit-action@v7
-        with:
-          commit_message: "chore(deps): refresh package-lock.json"
-          file_pattern: package-lock.json
-```
-
----
-
-## Build and commit compiled assets
-
-**Description:** For projects that ship a `dist/` folder (libraries, browser extensions, themes), build the assets in CI and commit them so consumers can install directly from the repo without a build step.
-
-```yaml
-name: Build dist
-
-on:
-  push:
-    branches: [main]
-
-jobs:
-  build:
-    runs-on: ubuntu-latest
-    permissions:
-      contents: write
-
-    steps:
-      - uses: actions/checkout@v5
-
-      - uses: actions/setup-node@v4
-        with:
-          node-version: 20
-          cache: npm
-
-      - run: npm ci
-      - run: npm run build
-
-      - uses: stefanzweifel/git-auto-commit-action@v7
-        with:
-          commit_message: "build: update dist/"
-          file_pattern: "dist/**"
-```
-
-> [!NOTE]
-> If `dist/` is in `.gitignore`, the Action will not pick up changes. See the [troubleshooting section in the README](README.md#change-to-file-is-not-detected).
-
----
-
-## Auto-generate API documentation
-
-**Description:** Tools like TypeDoc, Doxygen, Sphinx, or `cargo doc` generate documentation from source comments. Regenerate on every push to `main` and commit the output so the published docs always match the latest code.
-
-```yaml
-name: Docs
-
-on:
-  push:
-    branches: [main]
-
-jobs:
-  typedoc:
-    runs-on: ubuntu-latest
-    permissions:
-      contents: write
-
-    steps:
-      - uses: actions/checkout@v5
-
-      - uses: actions/setup-node@v4
-        with:
-          node-version: 20
-          cache: npm
-
-      - run: npm ci
-      - run: npx typedoc --out docs/api src/index.ts
-
-      - uses: stefanzweifel/git-auto-commit-action@v7
-        with:
-          commit_message: "docs: regenerate API reference"
-          file_pattern: "docs/api/**"
-```
-
----
-
-## Update README with generated content
-
-**Description:** Many projects keep dynamic sections in the README — a contributor list, a badge gallery, a table of contents, a list of supported plugins. Regenerate them on a schedule (or when a related file changes) and commit the result.
-
-```yaml
-name: Update contributors
-
-on:
-  schedule:
-    - cron: "0 0 * * 0" # weekly
-  workflow_dispatch:
-
-jobs:
-  contributors:
-    runs-on: ubuntu-latest
-    permissions:
-      contents: write
-
-    steps:
-      - uses: actions/checkout@v5
-
-      - uses: akhilmhdh/contributors-readme-action@v2.3.10
-        env:
-          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
-
-      - uses: stefanzweifel/git-auto-commit-action@v7
-        with:
-          commit_message: "docs: update contributors"
-          file_pattern: README.md
-```
-
----
-
-## Maintain a CHANGELOG
-
-**Description:** Generate or update `CHANGELOG.md` from commit history or release notes after each merge to `main`, and commit it back.
-
-```yaml
-name: Update CHANGELOG
-
-on:
-  push:
-    branches: [main]
-
-jobs:
-  changelog:
-    runs-on: ubuntu-latest
-    permissions:
-      contents: write
-
-    steps:
-      - uses: actions/checkout@v5
-        with:
-          fetch-depth: 0 # full history so the generator sees all commits
-
-      - uses: actions/setup-node@v4
-        with:
-          node-version: 20
-
-      - run: npx conventional-changelog -p angular -i CHANGELOG.md -s
-
-      - uses: stefanzweifel/git-auto-commit-action@v7
-        with:
-          commit_message: "docs: update CHANGELOG"
-          file_pattern: CHANGELOG.md
-```
-
----
-
-## Sync translations / i18n files
-
-**Description:** When translations are managed in an external service (Crowdin, Lokalise, Weblate) or extracted from source, pull or generate the latest catalogs on a schedule and commit them.
-
-```yaml
-name: Sync translations
-
-on:
-  schedule:
-    - cron: "0 3 * * *" # daily at 03:00 UTC
-
-jobs:
-  sync:
-    runs-on: ubuntu-latest
-    permissions:
-      contents: write
-
-    steps:
-      - uses: actions/checkout@v5
-
-      - name: Download translations
-        run: ./scripts/pull-translations.sh
-        env:
-          CROWDIN_TOKEN: ${{ secrets.CROWDIN_TOKEN }}
-
-      - uses: stefanzweifel/git-auto-commit-action@v7
-        with:
-          commit_message: "i18n: sync translations from Crowdin"
-          file_pattern: "locales/**/*.json"
-```
-
----
-
-## Publish a static site to a separate branch
-
-**Description:** Build a static site on `main` and push the generated output to a `gh-pages` branch so GitHub Pages can serve it. Use a second checkout directory for the publish branch so the source checkout and generated site do not get mixed together.
-
-Create the `gh-pages` branch once before using this workflow.
-
-```yaml
-name: Build site
-
-on:
-  push:
-    branches: [main]
-
-jobs:
-  build:
-    runs-on: ubuntu-latest
-    permissions:
-      contents: write
-
-    steps:
-      - uses: actions/checkout@v5
-        with:
-          path: source
-
-      - uses: actions/checkout@v5
-        with:
-          ref: gh-pages
-          path: site
-
-      - name: Build site
-        working-directory: source
-        run: ./build-site.sh # produces output in ./public
-
-      - name: Replace publish branch contents
-        run: |
-          find site -mindepth 1 -maxdepth 1 ! -name .git -exec rm -rf {} +
-          cp -R source/public/. site/
-
-      - uses: stefanzweifel/git-auto-commit-action@v7
-        with:
-          repository: site
-          branch: gh-pages
-          commit_message: "site: rebuild from ${{ github.sha }}"
-```
-
-> [!NOTE]
-> For most Pages workflows the official [`actions/deploy-pages`](https://github.com/actions/deploy-pages) is a better fit. Use this approach when you specifically want the build output stored in a branch.
-
----
-
-## Scheduled data refresh
-
-**Description:** Pull data from an external source on a schedule and commit it. Common examples: tracking statistics, snapshotting an API response, refreshing a cached dataset.
-
-```yaml
-name: Refresh stats
-
-on:
-  schedule:
-    - cron: "0 * * * *" # hourly
-  workflow_dispatch:
-
-jobs:
-  refresh:
-    runs-on: ubuntu-latest
-    permissions:
-      contents: write
-
-    steps:
-      - uses: actions/checkout@v5
-
-      - run: curl -sSL https://api.example.com/stats.json -o data/stats.json
-
-      - uses: stefanzweifel/git-auto-commit-action@v7
-        with:
-          commit_message: "data: refresh hourly stats"
-          file_pattern: "data/*.json"
-```
-
----
-
-## Create a release tag without a commit
-
-**Description:** Sometimes you want to tag the current HEAD as a release without committing any files. Use `create_git_tag_only` together with `tag_name` and `tagging_message`.
-
-```yaml
-name: Tag release
-
-on:
-  workflow_dispatch:
-    inputs:
-      version:
-        description: "Version to tag (e.g. v1.4.0)"
-        required: true
-
-jobs:
-  tag:
-    runs-on: ubuntu-latest
-    permissions:
-      contents: write
-
-    steps:
-      - uses: actions/checkout@v5
-
-      - uses: stefanzweifel/git-auto-commit-action@v7
-        with:
-          create_git_tag_only: true
-          tag_name: ${{ inputs.version }}
-          tagging_message: "Release ${{ inputs.version }}"
-```
-
----
-
-## Fail the build instead of pushing changes (drift check)
-
-**Description:** Sometimes you don't want a bot to push fixes — you want to fail the build so the contributor fixes them locally. Use the `changes_detected` output as a check: run the formatter, skip branch checkout/fetch/push, and fail if anything changed.
-
-```yaml
-name: Format check
-
-on: pull_request
-
-jobs:
-  check:
-    runs-on: ubuntu-latest
-    permissions:
-      contents: read
-
-    steps:
-      - uses: actions/checkout@v5
-
-      - uses: actions/setup-node@v4
-        with:
-          node-version: 20
-
-      - run: npx prettier --write .
-
-      - uses: stefanzweifel/git-auto-commit-action@v7
-        id: auto-commit
-        with:
-          skip_checkout: true
-          skip_fetch: true
-          skip_push: true
-
-      - name: Fail if formatting was needed
-        if: steps.auto-commit.outputs.changes_detected == 'true'
-        run: |
-          echo "::error::Code is not formatted. Run 'npx prettier --write .' locally."
-          exit 1
-```
-
----
-
-## Sign automated commits with GPG
-
-**Description:** If your branch protection rules require signed commits, the bot's commits need to be signed too. Import a GPG key first, then tell the Action to use the key's identity as the commit author.
-
-```yaml
-name: Format (signed)
-
-on: pull_request
-
-jobs:
-  format:
-    runs-on: ubuntu-latest
-    permissions:
-      contents: write
-
-    steps:
-      - uses: actions/checkout@v5
-        with:
-          ref: ${{ github.head_ref }}
-
-      - name: Import GPG key
-        id: import-gpg
-        uses: crazy-max/ghaction-import-gpg@v6
-        with:
-          gpg_private_key: ${{ secrets.GPG_PRIVATE_KEY }}
-          passphrase: ${{ secrets.GPG_PASSPHRASE }}
-          git_user_signingkey: true
-          git_commit_gpgsign: true
-
-      - run: npx prettier --write .
-
-      - uses: stefanzweifel/git-auto-commit-action@v7
-        with:
-          commit_message: "style: apply prettier"
-          commit_user_name: ${{ steps.import-gpg.outputs.name }}
-          commit_user_email: ${{ steps.import-gpg.outputs.email }}
-          commit_author: "${{ steps.import-gpg.outputs.name }} <${{ steps.import-gpg.outputs.email }}>"
-```
-
-See discussion [#334](https://github.com/stefanzweifel/git-auto-commit-action/discussions/334) for background.
-
----
-
-## Squash automated changes into the previous commit
-
-**Description:** Avoid noisy "apply automatic changes" commits by amending the last commit instead. Useful when the bot fix is trivial and you don't want a separate entry in the history.
-
-> [!CAUTION]
-> Amending rewrites history. Only use this on branches where force-pushing is acceptable (typically PR branches, never `main`).
-
-```yaml
-name: Format (amend)
-
-on: pull_request
-
-jobs:
-  format:
-    runs-on: ubuntu-latest
-    permissions:
-      contents: write
-
-    steps:
-      - uses: actions/checkout@v5
-        with:
-          ref: ${{ github.head_ref }}
-          fetch-depth: 2 # need previous commit for --amend
-
-      - run: npx prettier --write .
-
-      - name: Read previous commit metadata
-        id: last
-        run: |
-          echo "message=$(git log -1 --pretty=%s)" >> $GITHUB_OUTPUT
-          echo "author=$(git log -1 --pretty='%an <%ae>')" >> $GITHUB_OUTPUT
-
-      - uses: stefanzweifel/git-auto-commit-action@v7
-        with:
-          commit_message: ${{ steps.last.outputs.message }}
-          commit_author: ${{ steps.last.outputs.author }}
-          commit_options: "--amend --no-edit"
-          push_options: "--force"
-          skip_fetch: true
-```
-
-See discussion [#159](https://github.com/stefanzweifel/git-auto-commit-action/issues/159#issuecomment-845347950) for details.

README.md

@@ -20,7 +20,7 @@ If your use case is not covered by git-auto-commit, you might want to check out
 
 Adding git-auto-commit to your Workflow only takes a couple lines of code.
 
-1. Set the `contents`-permission of the default GITHUB_TOKEN to `write`. (Required to push new commits to the repository)
+1. Set the `contents`-permission of the default GITHUB_TOKEN to `true`. (Required to push new commits to the repository)
 2. Add the following step at the end of your job, after other steps that might add or change files.
 
 ```yaml
@@ -84,7 +84,7 @@ The following is an extended example with all available options.
     # - https://git-scm.com/docs/gitglossary#Documentation/gitglossary.txt-aiddefpathspecapathspec
     file_pattern: '*.php src/*.js tests/*.js'
 
-    # Optional. Relative file path under $GITHUB_WORKSPACE to the repository.
+    # Optional. Local file path to the repository.
     # Defaults to the root of the repository.
     repository: .
 
@@ -177,8 +177,6 @@ jobs:
         commit_message: Apply php-cs-fixer changes
 ```
 
-See [EXAMPLES.md](EXAMPLES.md) for more scenarios, including auto-formatting, dependency updates, generated docs, release tagging, drift checks, and GPG-signed commits.
-
 ## Inputs
 
 Checkout [`action.yml`](https://github.com/stefanzweifel/git-auto-commit-action/blob/master/action.yml) for a full list of supported inputs.
@@ -258,13 +256,13 @@ storing the token as a secret in your repository and then passing the new token
 If you create a personal access token (classic), apply the `repo` and `workflow` scopes.
 If you create a fine-grained personal access token, apply the `Contents`-permissions.
 
-If you work in an organization and don't want to create a PAT from your personal account, we recommend using a [robot account](https://docs.github.com/en/get-started/learning-about-github/types-of-github-accounts) for the token.
+If you work in an organization and don't want to create a PAT from your personal account, we recommend using a [robot account](https://docs.github.com/en/github/getting-started-with-github/types-of-github-accounts) for the token.
 
 ### Prevent Infinite Loop when using a Personal Access Token
 
 If you're using a Personal Access Token (PAT) to push commits to GitHub repository, the resulting commit or push can trigger other GitHub Actions workflows. This can result in an infinite loop.
 
-If you would like to prevent this, you can add `skip-checks:true` to the commit message. See [Skipping workflow runs](https://docs.github.com/en/actions/how-tos/manage-workflow-runs/skip-workflow-runs) for details.
+If you would like to prevent this, you can add `skip-checks:true` to the commit message. See [Skipping workflow runs](https://docs.github.com/en/actions/managing-workflow-runs/skipping-workflow-runs) for details.
 
 ### Change to file is not detected
 
@@ -276,7 +274,7 @@ Does your workflow change a file, but "git-auto-commit" does not detect the chan
 
 If your commit message should span multiple lines, you have to create a separate step to generate the string. 
 
-The example below can be used as a starting point to generate a multiline commit meesage. Learn more how multiline strings in GitHub Actions work in the [GitHub documentation](https://docs.github.com/en/actions/reference/workflows-and-actions/workflow-commands#multiline-strings).
+The example below can be used as a starting point to generate a multiline commit meesage. Learn more how multiline strings in GitHub Actions work in the [GitHub documentation](https://docs.github.com/en/actions/using-workflows/workflow-commands-for-github-actions#multiline-strings).
 
 ```yaml
     # Building a multiline commit message
@@ -331,16 +329,15 @@ See discussion [#334](https://github.com/stefanzweifel/git-auto-commit-action/di
 
 ### Use in forks from private repositories
 
-
 By default, GitHub Actions doesn't run Workflows on forks from **private** repositories. To enable Actions for **private** repositories enable "Run workflows from pull requests" in your repository settings.
 
-See [this announcement from GitHub](https://github.blog/2020-08-03-github-actions-improvements-for-fork-and-pull-request-workflows/) or the [GitHub docs](https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository#enabling-workflows-for-private-repository-forks) for details.
+See [this announcement from GitHub](https://github.blog/2020-08-03-github-actions-improvements-for-fork-and-pull-request-workflows/) or the [GitHub docs](https://docs.github.com/en/github/administering-a-repository/disabling-or-limiting-github-actions-for-a-repository#enabling-workflows-for-private-repository-forks) for details.
 
 
 ### Use in forks from public repositories
 
 > [!NOTE] 
-> This Action technically works with forks. However, please note that the combination of triggers and their options can cause issues. Please read [the documentation](https://docs.github.com/en/actions/reference/workflows-and-actions/events-that-trigger-workflows) on which triggers GitHub Actions support.\
+> This Action technically works with forks. However, please note that the combination of triggers and their options can cause issues. Please read [the documentation](https://docs.github.com/en/free-pro-team@latest/actions/reference/events-that-trigger-workflows) on which triggers GitHub Actions support.\
 > Ensure your contributors enable "Allow edits by maintainers" when opening a pull request. ([Learn more](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/allowing-changes-to-a-pull-request-branch-created-from-a-fork)) \
 > \
 > **If you use this Action in combination with a linter/fixer, it's easier if you run the Action on `push` on your `main`-branch.**
@@ -349,7 +346,7 @@ See [this announcement from GitHub](https://github.blog/2020-08-03-github-action
 > Due to limitations of GitHub, this Action currently can't push commits to a base repository, if the fork _lives_ under an organisation. See [github/community#6634](https://github.com/orgs/community/discussions/5634) and [this comment](https://github.com/stefanzweifel/git-auto-commit-action/issues/211#issuecomment-1428849944) for details.
 
 By default, this Action will not run on Pull Requests which have been opened by forks. (This is a limitation by GitHub, not by us.)   
-However, there are a couple of ways to use this Action in Workflows that should be triggered by forked repositories.
+However, there are a couple of ways to use this Actions in Workflows that should be triggered by forked repositories.
 
 ### Workflow should run in **base** repository
 
@@ -420,7 +417,7 @@ Finally, you have to use `push_options: '--force'` to overwrite the git history
 The steps in your workflow might look like this:
 
 ```yaml
-- uses: actions/checkout@v4
+- uses: actions/checkout@4
   with:
     # Fetch the last 2 commits instead of just 1. (Fetching just 1 commit would overwrite the whole history)
     fetch-depth: 2
@@ -445,7 +442,6 @@ The steps in your workflow might look like this:
 See discussion in [#159](https://github.com/stefanzweifel/git-auto-commit-action/issues/159#issuecomment-845347950) for details.
 
 ## Troubleshooting
-
 ### Action does not push commit to repository
 
 Make sure to [checkout the correct branch](#checkout-the-correct-branch).
@@ -464,7 +460,7 @@ If you still can't push the commit, and you're using branch protection rules or
 The default `GITHUB_TOKEN` issued by GitHub Action does not have permission to make changes to workflow files located in `.github/workflows/`.
 To fix this, please create a personal access token (PAT) and pass the token to the `actions/checkout`-step in your workflow. (Similar to [how to push to protected branches](https://github.com/stefanzweifel/git-auto-commit-action?tab=readme-ov-file#push-to-protected-branches)).
 
-If a PAT does not work for you, you could also create a new GitHub app and use its token in your workflows. See [this comment in #87](https://github.com/stefanzweifel/git-auto-commit-action/issues/87#issuecomment-1939138661) for details.
+If a PAT does not work for you, you could also create a new GitHub app and use it's token in your workflows. See [this comment in #87](https://github.com/stefanzweifel/git-auto-commit-action/issues/87#issuecomment-1939138661) for details.
 
 See [#322](https://github.com/stefanzweifel/git-auto-commit-action/issues/322) for details and discussions around this topic.
 
@@ -484,13 +480,13 @@ If you create a fine-grained personal access token, apply the `Contents`-permiss
     # We pass the "PAT" secret to the checkout action; if no PAT secret is available to the workflow runner (eg. Dependabot) we fall back to the default "GITHUB_TOKEN".
     token: ${{ secrets.PAT || secrets.GITHUB_TOKEN }}
 ```
-You can learn more about Personal Access Token in the [GitHub documentation](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens).
+You can learn more about Personal Access Token in the [GitHub documentation](https://docs.github.com/en/github/authenticating-to-github/creating-a-personal-access-token).
 
 
 > [!TIP] 
 > If you're working in an organisation, and you don't want to create the PAT from your personal account, we recommend using a bot-account for such tokens.
 
-If you go the "force pushes" route, you have to enable force pushes to a protected branch (see [documentation](https://docs.github.com/en/github/administering-a-repository/enabling-force-pushes-to-a-protected-branch)) and update your Workflow to use force push like this.
+If you go the "force pushes" route, you have to enable force pushes to a protected branch (see [documentation](https://help.github.com/en/github/administering-a-repository/enabling-force-pushes-to-a-protected-branch)) and update your Workflow to use force push like this.
 
 ```yaml
     - uses: stefanzweifel/git-auto-commit-action@v7
@@ -513,7 +509,7 @@ See [Issue #227](https://github.com/stefanzweifel/git-auto-commit-action/issues/
 
 ### Custom `file_pattern`, changed files but seeing "Working tree clean. Nothing to commit." in the logs
 
-If you're using a custom `file_pattern` and the Action does not detect the changes made in your workflow, you're probably running into a globbing issue.
+If you're using a custom `file_pattern` and the Action does not detect the changes made in your worfklow, you're probably running into a globbing issue.
 
 Let's imagine you use `file_pattern: '*.md'` to detect and commit changes to all Markdown files in your repository.
 If your Workflow now only updates `.md`-files in a subdirectory, but you have an untouched `.md`-file in the root of the repository, the git-auto-commit Action will display "Working tree clean. Nothing to commit." in the Workflow log.
@@ -549,10 +545,10 @@ yarn test
 
 ## Versioning
 
-We use [SemVer](https://semver.org/) for versioning. For the versions available, see the [tags on this repository](https://github.com/stefanzweifel/git-auto-commit-action/tags).
+We use [SemVer](http://semver.org/) for versioning. For the versions available, see the [tags on this repository](https://github.com/stefanzweifel/git-auto-commit-action/tags).
 
 We also provide major version tags to make it easier to always use the latest release of a major version. For example, you can use `stefanzweifel/git-auto-commit-action@v7` to always use the latest release of the current major version.
-(More information about this [here](https://docs.github.com/en/actions/building-actions/about-actions#versioning-your-action).)
+(More information about this [here](https://help.github.com/en/actions/building-actions/about-actions#versioning-your-action).)
 
 ## Credits
 

UPGRADING.md

@@ -4,8 +4,7 @@
 
 The previously removed options `create_branch`, `skip_fetch`, and `skip_checkout` have been reintroduced in git-auto-commit v7. If you had removed these options from your workflows when upgrading to v6, you can now add them back if needed.
 
-Tagging a commit has been reworked. In addition to the existing `tagging_message`-option, a new `tag_name` option has been added. If you were using `tagging_message`, you can continue to do so, but if you want to specify a custom tag name and tag message, you can now use the `tag_name` and `tagging_message` options.
+Tagging a commit has been reworked. In addition to the existing `tagging_message`-option, a new `tag_name` option has been added. If you were using `tagging_message`, you can continue to do so, but if you want to specify a custom tag name and tag message, you can now use the `tag_name` and `tagging_message` option.
-
 (Specifying a `tagging_message` without a `tag_name` will create a tag with the name and message both set to the value of `tagging_message`.)
 
 ## From v5 to v6

action.yml

@@ -25,11 +25,11 @@ inputs:
     required: false
     default: ''
   file_pattern:
-    description: File pattern used for `git add` and the dirty-check (`git status`). Supports multiple space-separated patterns. For example `src/*.js`
+    description: File pattern used for `git add`. For example `src/*.js`
     required: false
     default: '.'
   repository:
-    description: Relative file path under $GITHUB_WORKSPACE to the git repository. Defaults to the current directory (`.`)
+    description: Local file path to the git repository. Defaults to the current directory (`.`)
     required: false
     default: '.'
   commit_user_name:
@@ -74,11 +74,9 @@ inputs:
     default: false
   disable_globbing:
     description: Stop the shell from expanding filenames (https://www.gnu.org/software/bash/manual/html_node/Filename-Expansion.html)
-    required: false
     default: false
   create_branch:
     description: Create new branch with the name of `branch`-input in local and remote repository, if it doesn't exist yet.
-    required: false
     default: false
   create_git_tag_only:
     description: Perform a clean git tag and push, without commiting anything
@@ -86,17 +84,16 @@ inputs:
     default: false
   internal_git_binary:
     description: Internal use only! Path to git binary used to check if git is available. (Don't change this!)
-    required: false
     default: git
 
 
 outputs:
   changes_detected:
-    description: Value is "true" if matching changes were detected and committed. Value is "false" if no matching changes were detected or only CRLF changes were staged. Not set in `create_git_tag_only` mode.
+    description: Value is "true", if the repository was dirty and file changes have been detected. Value is "false", if no changes have been detected.
   commit_hash:
-    description: Full hash of the created commit. Only set when a commit was actually made (i.e. `changes_detected` is "true").
+    description: Full hash of the created commit. Only present if the "changes_detected" output is "true".
   create_git_tag_only:
-    description: Set to "true" when the action ran in `create_git_tag_only` mode. Never set to "false".
+    description: Value is "true", if a git tag was created using the `create_git_tag_only`-input.
 
 runs:
   using: 'node24'