Prepare JetBrains/ReSharper-InspectCode for reusable Action release v0.13

[Copilot]

• Change tool-version default from 2025.3.3 to 2026.1.0.1 in action.yml
• Update the matching default in the README.md inputs table and example

Original prompt

Goal: Prepare JetBrains/ReSharper-InspectCode to be released/versioned as a reusable GitHub Action, and open a PR to main.

Context:

• Repository: JetBrains/ReSharper-InspectCode (repo id 624843267)
• User confirmed they have permission to create PRs in this repository.
• Requested release tag: EXACT v0.13.
• Target branch: main.
• They want a PR (not direct push). Note: tags are created after merge; PR should prepare the action metadata/docs so maintainers can tag v0.13 on the merge commit.

Tasks (do in PR):

1. Inspect repository for existing GitHub Action implementation.
   • Look for action.yml / action.yaml, Dockerfile, dist/, package.json, or composite action structure.
   • Determine whether this repo is already an Action, or needs to be turned into one.
2. If action metadata is missing or incomplete, add/adjust it so the repo works as a GitHub Action:
   • Prefer a composite action if it can call existing scripts/binaries.
   • Otherwise use a Docker action if the repo already ships a container.
   • Otherwise use a JavaScript action if appropriate, including building and committing dist if required.
   • Provide inputs and outputs that make sense for InspectCode (e.g., solution path, settings, output format/path, verbosity, fail thresholds).
   • Ensure runs section is correct and action is runnable on GitHub-hosted runners.
3. Add/Update documentation:
   • Update README with a “Usage” section including an example workflow pinning to JetBrains/ReSharper-InspectCode@v0.13.
   • Document inputs, defaults, and example outputs/artifacts.
4. Add CI validation for the action where feasible:
   • Add a basic workflow (e.g., .github/workflows/action-ci.yml) that runs on PRs and exercises the action in a minimal way (linting/metadata validation, or a smoke test).
5. Ensure repo contains a clear release process note:
   • In README or CONTRIBUTING, add short instructions: after merging PR, create tag v0.13 on the merge commit; optionally create GitHub Release.
6. Open a PR to main with a clear title referencing v0.13 action release preparation.

Constraints:

• Do not create the tag in the PR; only prepare the repository for tagging.
• Keep changes minimal and consistent with existing tooling.
• If the repo already contains action metadata, focus on documentation/CI/release notes and ensuring everything is correct for tagging v0.13.

The following is the prior conversation context from the user's chat exploration (may be truncated):

User: Create a new action release

Assistant: To create a new Actions release for JetBrains/ReSharper-InspectCode, I need one clarification: what do you mean by “action release”?

Pick one option (just reply with A, B, or C) and include the requested info:

A) Create a GitHub Release (tag + release notes)

• Version/tag name (e.g., v1.2.3):
• Target branch/commit (e.g., main):
• Release title + notes (or “auto-generate”):

B) Release this repo as a reusable GitHub Action (Marketplace-style: tags like v1, v1.2, v1.2.3)

• What version should this be (e.g., v1.0.0)?
• Should I also create/move the major tag (e.g., v1 → v1.0.0)?

C) Add a new GitHub Actions workflow that performs releases (e.g., on tag push)

• What should it release (NuGet? GitHub Release artifacts? Docker? just zip artifacts?)
• Trigger: tag pattern (e.g., v*.*.*) or manual (workflow_dispatch)?

Also: do you want me to open a PR with the changes (workflow files, action metadata, etc.), or do you have permission for me to push directly to the repo?

User: B, v0.13

Assistant: I can do B (publish as a reusable GitHub Action release), but I need two specifics before I make changes:

1. Should the tag be exactly v0.13 (as given), or do you want a semver patch too (e.g., v0.13.0)?
2. Should I also create/move the major/minor floating tag:
   • v0 → v0.13
   • v0.13 → (this release)

Also confirm the default branch to tag from (usually main or master) and whether you want this done via a PR (recommended) or a direct tag (no PR, just create tag/release).

User: Exact v0.13 on main with PR

Assistant: To do this with a PR, I’ll need to update the repo so the Action can be versioned/tagged (tags/releases themselves aren’t created via PR).

Here’s what I’m going to do in JetBrains/ReSharper-InspectCode:

1. Verify the repo has GitHub Action metadata (action.yml/action.yaml) and is structured as a reusable action.
2. If missing, add the minimal Action entrypoint + metadata (and README usage snippet), wired to whatever the repo already does (likely a wrapper that runs InspectCode).
3. Add documentation for using the action pinned to @v0.13.
4. Open a PR against main.
5. After merge, you (or a maintainer) create the tag v0.13 pointing at the merge commit.

Before I proceed, one important constraint: **I can’t open a PR unless you confirm you have permission to create branches/PRs ...

This pull request was created from Copilot chat.