port over github actions from pxt-microbit

[riknoll]

as the title says, this ports over the github actions workflows from pxt-microbit. also updates pxt-core to the version required for npm trusted publishing

To fix this problem, you should explicitly define a permissions key in the workflow. This can be done at the top-level to cover all jobs, or at the job level for more granularity. In this workflow, since the jobs only need to read repository information and pull request metadata, the most restrictive appropriate permission is contents: read (and potentially pull-requests: read, but for most metadata-only workflows, contents: read suffices—however, for querying PRs, pull-requests: read is safest and recommended). The fix is to add:

permissions:
  contents: read
  pull-requests: read

at the top of the file, after the name: line and before the on: block, or at the check-pr job level. Placing it at the workflow root is simplest and will apply to all jobs, as the example recommends.

To address the issue, add a permissions: block to restrict the GITHUB_TOKEN to least privilege, specifically at the root of the workflow (recommended, so all jobs inherit it unless individually overridden). In this workflow, no steps interact with the repository or perform any write operations; the only activity is reading environment variables and echoing outputs, so contents: read is suitable. The fix consists of inserting a block like:

permissions:
  contents: read

directly below the workflow name: field and before on: (or anywhere before jobs:). No other changes, imports, or definitions are required.

To fix this problem, add an explicit permissions: block at the root of your workflow YAML. Set the global default to contents: read for least privilege. For the job that needs to push a tag to the repository (tag-version), override the global permissions by setting permissions: contents: write for that job only. This approach minimizes exposure by limiting write rights to only where necessary. You should add the global permissions: block after the name key (line 1) and before the on key (line 3), and add a permissions: block specifically for the tag-version job.

---

The best fix is to add an explicit permissions block to the workflow, ideally at the root level so that all jobs inherit it. Since the only job requiring write access is tag-version (for tagging and pushing a tag), most jobs could run with contents: read, while tag-version requires contents: write. If you want maximum specificity and minimum permissions, set permissions: contents: read at the root/workflow level, and override with permissions: contents: write for the tag-version job. This matches the recommendations and examples in the warning background.

Steps:

1. Add at the top of the workflow:

   permissions:
     contents: read

2. Under tag-version:, add:

   permissions:
     contents: write

No new imports or new methods are needed; this is a declarative change in the YAML configuration.

---

To resolve the issue, add a permissions block to the workflow, specifying only the minimal required scopes for each job. At a minimum, the workflow requires contents: read to check out code, and specifically in the tag-version job, it also needs contents: write to create and push new tags. You should define the least required permissions at job level where escalation is needed (tag-version), otherwise use contents: read globally. This fix should be made in .github/workflows/tag-bump-commit.yml by adding permissions: contents: read at the top level, and overriding with permissions: contents: write for the tag-version job.

---

The best way to fix this problem is to add a permissions block to the workflow, either at the root (for all jobs) or per-job as needed. The tag-version job requires contents: write permission to create and push tags. Other jobs—check-merge, check-merge-outputs, not-tag-version, and return—most likely only need contents: read or none at all, depending on their operations (they mostly echo outputs, run shell commands, and use reusable workflow). To follow principle of least privilege, specify the needed permissions for each job. For maximum clarity and security, add minimal permissions per job, with broad permissions avoided wherever possible.

In detail:

• For jobs that only read workflow state and echo outputs (not-tag-version, return, check-merge-outputs, check-merge): set permissions: contents: read.
• For tag-version: set permissions: contents: write since it creates tags (write to repository contents).
• Insert the permissions: key at the correct indentation level for each job.

To fix the problem, add a permissions block at the root of the workflow file (.github/workflows/tag-bump-commit.yml). This block should specify the minimal permissions required for the workflow. Because there are steps that need to create and push tags (write access to contents) but do not appear to access other resources like issues or pull requests, set contents: write and consider other permissions as needed. This block must be inserted below the workflow name, before on:. If, upon future review, any jobs require additional permissions (such as pull-requests: write), adjust accordingly at the job level. For now, the single best fix is to add, after line 1, the following block:

permissions:
  contents: write

Optionally, if jobs only require read access, use read, but given the workflow's need to create tags (git push), write is required.