Merge pull request #33 from actions/dependabot/github_actions/issue-ops/releaser-3

Bump issue-ops/releaser from 2 to 3

.checkov.yaml

@@ -0,0 +1,4 @@
+quiet: true
+skip-check:
+  - CKV_DOCKER_2
+  - CKV_DOCKER_3

.github/copilot-instructions.md

@@ -0,0 +1,69 @@
+# Copilot Instructions
+
+This GitHub Action is written as a Docker container that invokes an entrypoint
+script. The entrypoint script is responsible for invoking the main logic of the
+action.
+
+## Repository Structure
+
+| Path                 | Description                         |
+| -------------------- | ----------------------------------- |
+| `.devcontainer/`     | Development Container Configuration |
+| `.github/`           | GitHub Configuration                |
+| `.markdown-lint.yml` | Markdown Linter Configuration       |
+| `.prettierrc.yml`    | Prettier Formatter Configuration    |
+| `.yaml-lint.yml`     | YAML Linter Configuration           |
+| `action.yml`         | GitHub Action Metadata              |
+| `CODEOWNERS`         | Code Owners File                    |
+| `Dockerfile`         | Dockerfile for the Action           |
+| `entrypoint.sh`      | Entrypoint Script                   |
+| `LICENSE`            | License File                        |
+| `README.md`          | Project Documentation               |
+
+## General Coding Guidelines
+
+- Follow standard shell scripting conventions and best practices
+- Changes should maintain consistency with existing patterns and style
+- Document changes clearly and thoroughly, including updates to existing
+  comments when appropriate
+- Do not include basic, unnecessary comments that simply restate what the code
+  is doing (focus on explaining _why_, not _what_)
+- Use consistent error handling patterns throughout the codebase
+- Keep functions focused and manageable
+- Use descriptive variable and function names that clearly convey their purpose
+- When suggesting code changes, always opt for the most maintainable approach.
+  Try your best to keep the code clean and follow "Don't Repeat Yourself" (DRY)
+  principles
+- Avoid unnecessary complexity and always consider the long-term maintainability
+  of the code
+
+### Versioning
+
+GitHub Actions are versioned using branch and tag names. The version should
+follow [Semantic Versioning](https://semver.org/) principles.
+
+## Pull Request Guidelines
+
+When creating a pull request (PR), please ensure that:
+
+- Keep changes focused and minimal (avoid large changes, or consider breaking
+  them into separate, smaller PRs)
+- Formatting checks pass
+- Linting checks pass
+- If necessary, the `README.md` file is updated to reflect any changes in
+  functionality or usage
+
+The body of the PR should include:
+
+- A summary of the changes
+- A special note of any changes to dependencies
+- A link to any relevant issues or discussions
+- Any additional context that may be helpful for reviewers
+
+## Code Review Guidelines
+
+When performing a code review, please follow these guidelines:
+
+- If there are changes that modify the functionality/usage of the action,
+  validate that there are changes in the `README.md` file that document the new
+  or modified functionality

.github/prompts/create-release-notes.prompt.md

@@ -0,0 +1,34 @@
+# Create Release Notes
+
+You are an expert technical writer tasked with creating release notes for
+updates to this repository. Your specific task is to generate release notes that
+are clear, concise, and useful for developers and users of the project.
+
+## Guidelines
+
+Ensure you adhere to the following guidelines when creating release notes:
+
+- Use a clear and consistent format for the release notes
+- Include a summary of the changes made in the release
+- Highlight any new features, improvements, or bugfixes
+- If applicable, include instructions for upgrading or migrating to the new
+  version
+- Use technical language that is appropriate for the audience, but avoid jargon
+  that may not be understood by all users
+- Ensure that the release notes are easy to read and navigate
+- Include relevant issue or PR numbers where applicable
+- Use proper Markdown formatting
+- Use code blocks for commands, configuration examples, or code changes
+- Use note and warning callouts for important information
+
+## Versioning
+
+GitHub Actions are versioned using branch and tag names. The version in the
+project's `package.json` should reflect the changes made in the codebase and
+follow [Semantic Versioning](https://semver.org/) principles. Depending on the
+nature of the changes, please make sure to adjust the release notes accordingly:
+
+- For **major** changes, include a detailed description of the breaking changes
+  and how users can adapt to them
+- For **minor** changes, highlight new features and improvements
+- For **patch** changes, focus on bugfixes and minor improvements

.github/workflows/cd.yml

@@ -35,14 +35,14 @@ jobs:
     steps:
       - name: Checkout
         id: checkout
-        uses: actions/checkout@v4
+        uses: actions/checkout@v6
         with:
           fetch-tags: true
           ref: main
 
       - name: Check Version
         id: version
-        uses: issue-ops/semver@v2
+        uses: issue-ops/semver@v3
         with:
           check-only: true
           manifest-path: ${{ env.MANIFEST_PATH }}
@@ -59,7 +59,7 @@ jobs:
       # - `v1`
       - name: Set Image Tags
         id: tags
-        uses: actions/github-script@v7
+        uses: actions/github-script@v8
         with:
           script: |
             const version = '${{ steps.version.outputs.version }}'
@@ -110,6 +110,6 @@ jobs:
 
       - name: Create Release
         id: release
-        uses: issue-ops/releaser@v2
+        uses: issue-ops/releaser@v3
         with:
           tag: v${{ steps.version.outputs.version }}

.github/workflows/ci.yml

@@ -2,6 +2,8 @@ name: Continuous Integration
 
 on:
   pull_request:
+    branches:
+      - main
   push:
     branches:
       - main
@@ -27,7 +29,7 @@ jobs:
     steps:
       - name: Checkout
         id: checkout
-        uses: actions/checkout@v4
+        uses: actions/checkout@v6
 
       - name: Setup Docker BuildX
         id: setup-buildx

.github/workflows/linter.yml

@@ -1,7 +1,14 @@
+# This workflow will lint the entire codebase using the
+# `super-linter/super-linter` action.
+#
+# For more information, see the super-linter repository:
+#     https://github.com/super-linter/super-linter
 name: Lint Codebase
 
 on:
   pull_request:
+    branches:
+      - main
   push:
     branches:
       - main
@@ -19,14 +26,18 @@ jobs:
     steps:
       - name: Checkout
         id: checkout
-        uses: actions/checkout@v4
+        uses: actions/checkout@v6
         with:
           fetch-depth: 0
 
       - name: Lint Codebase
         id: super-linter
-        uses: super-linter/super-linter/slim@v7
+        uses: super-linter/super-linter/slim@v8
         env:
           DEFAULT_BRANCH: main
           GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+          LINTER_RULES_PATH: ${{ github.workspace }}
           VALIDATE_ALL_CODEBASE: false
+          VALIDATE_BIOME_FORMAT: false
+          VALIDATE_BIOME_LINT: false
+          VALIDATE_GITHUB_ACTIONS_ZIZMOR: false

.github/workflows/version-check.yml

@@ -27,13 +27,13 @@ jobs:
     steps:
       - name: Checkout
         id: checkout
-        uses: actions/checkout@v4
+        uses: actions/checkout@v6
         with:
           fetch-tags: true
 
       - name: Check Version
         id: check-version
-        uses: issue-ops/semver@v2
+        uses: issue-ops/semver@v3
         with:
           check-only: true
           manifest-path: ${{ env.MANIFEST_PATH }}

.gitignore

@@ -21,5 +21,4 @@ Thumbs.db
 
 # IDE files
 .idea
-.vscode
 *.code-workspace

.vscode/mcp.json

@@ -0,0 +1,9 @@
+{
+  "servers": {
+    "github": {
+      "url": "https://api.githubcopilot.com/mcp/",
+      "type": "http"
+    }
+  },
+  "inputs": []
+}

.vscode/settings.json

@@ -0,0 +1,15 @@
+{
+  "github.copilot.chat.reviewSelection.instructions": [
+    {
+      "text": "Review the code changes carefully before accepting them."
+    }
+  ],
+  "github.copilot.chat.commitMessageGeneration.instructions": [
+    {
+      "text": "Use conventional commit message format."
+    }
+  ],
+  "github.copilot.chat.pullRequestDescriptionGeneration.instructions": [
+    { "text": "Always include a list of key changes." }
+  ]
+}

Dockerfile

@@ -1,5 +1,5 @@
 # Set the base image to use for subsequent instructions.
-FROM alpine:3.22
+FROM alpine:3.23
 
 # Set the working directory inside the container.
 WORKDIR /usr/src
@@ -7,5 +7,12 @@ WORKDIR /usr/src
 # Copy any source file(s) required for the action.
 COPY entrypoint.sh .
 
+# Create a non-root user and switch to it.
+RUN addgroup -S actiongroup && adduser -S actionuser -G actiongroup && \
+    chown -R actionuser:actiongroup /usr/src && \
+    chmod +x /usr/src/entrypoint.sh
+
+USER actionuser
+
 # Configure the container to be run as an executable.
 ENTRYPOINT ["/usr/src/entrypoint.sh"]

README.md

@@ -1,8 +1,7 @@
-# Container Prebuilt Action Template
+# Create a Container Prebuilt Action
 
 [![GitHub Super-Linter](https://github.com/actions/container-prebuilt-action/actions/workflows/linter.yml/badge.svg)](https://github.com/super-linter/super-linter)
-![CI](https://github.com/actions/container-prebuilt-action/actions/workflows/ci.yml/badge.svg)
-![CD](https://github.com/actions/container-prebuilt-action/actions/workflows/cd.yml/badge.svg)
+![Continuous Integration](https://github.com/actions/container-prebuilt-action/actions/workflows/ci.yml/badge.svg)
 
 Use this template to bootstrap the creation of a container action. :rocket:
 
@@ -177,7 +176,7 @@ So, what are you waiting for? Go ahead and start customizing your action!
 Your action is now published! :rocket:
 
 For information about versioning your action, see
-[Versioning](https://github.com/actions/toolkit/blob/master/docs/action-versioning.md)
+[Versioning](https://github.com/actions/toolkit/blob/main/docs/action-versioning.md)
 in the GitHub Actions toolkit.
 
 ## Releasing Versions
@@ -198,7 +197,7 @@ As part of the pull request, make sure to update the
 
 After testing, you can create version tag(s) that developers can use to
 reference different stable versions of your action. For more information, see
-[Versioning](https://github.com/actions/toolkit/blob/master/docs/action-versioning.md)
+[Versioning](https://github.com/actions/toolkit/blob/main/docs/action-versioning.md)
 in the GitHub Actions toolkit.
 
 To include the action in a workflow in another repository, you can use the
@@ -209,7 +208,7 @@ hash.
 steps:
   - name: Checkout
     id: checkout
-    uses: actions/checkout@v3
+    uses: actions/checkout@v4
 
   - name: Test Local Action
     id: test-action