[Adhoc] Add GHA build plugin files in release branch v0.9.0 for v0.9.x patches

[mwaiyee]

• Add GHA plugin workflows to run patches for v0.9.x on workflow_dispatch only

Merge Checklist

Please cross check this list if additions / modifications needs to be done on top of your core changes and tick them off. Reviewer can as well glance through and help the developer if something is missed out.

• Automated Tests (Jasmine integration tests, Unit tests, and/or Performance tests)
• Updated Manual tests / Demo Config
• Documentation (Application guide, Admin guide, Markdown, Readme and/or Wiki)
• Verified that local development environment is working with latest changes (integrated with latest develop branch)
• following best practices in code review doc

[Copilot]

Pull Request Overview

This PR adds three GitHub Actions workflow files to the v0.9.0 release branch to support patch builds for v0.9.x versions, triggered only through manual workflow dispatch.

• Adds specialized patch build workflows for UI, functions, and flows plugins
• Configures workflows to run only on workflow_dispatch events for v0.9.x maintenance
• Sets up version management and NPM publishing for patch releases

Reviewed Changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 3 comments.

File	Description
.github/workflows/patch-ui-plugin-ci.yml	UI plugin patch build workflow with Homebrew setup and yarn publishing
.github/workflows/patch-functions-plugin-ci.yml	Functions plugin patch build workflow with Deno and matrix strategy
.github/workflows/patch-flows-plugin-ci.yml.yml	Flows plugin patch build workflow with matrix strategy for multiple packages

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[Copilot]

The workflow includes pull_request and push triggers but the build job only runs on workflow_dispatch (line 73). This creates inconsistent behavior where the check_file_changes job may run on PR/push events but the build job will never execute, making these triggers ineffective.

[Copilot]

The workflow defines pull_request and push triggers but the build job has no conditional check to prevent it from running on these events. This contradicts the PR description which states workflows should run on workflow_dispatch only.

Suggested change

	pull_request:
	types: [opened, ready_for_review, reopened, synchronize]
	push:
	branches:
	- develop

[Copilot]

Similar to the other patch workflows, this defines pull_request and push triggers but the build job only runs on workflow_dispatch (line 75). This creates inconsistent trigger behavior that doesn't match the stated purpose of manual-only patch workflows.

Suggested change

	pull_request:
	types: [opened, ready_for_review, reopened, synchronize]
	push:
	branches:
	- develop
	# (Removed pull_request and push triggers to ensure manual-only workflow)

To fix the problem, explicitly add a permissions: block at the workflow root, immediately after the name: line (but before on:) or after on:, and set it to contents: read as a minimal default. This ensures that, unless a job needs more, all workflow jobs will receive a read-only GITHUB_TOKEN. If any jobs require greater permissions, those jobs should receive a more permissive override, but for the snippet shown, contents: read is likely sufficient.

How to fix:

• In .github/workflows/patch-flows-plugin-ci.yml.yml, add a permissions: key with contents: read at the workflow root level, e.g., between the name: and on: blocks (after line 1 and before line 3).
• This will apply to all jobs in the workflow unless they have their own permissions: block.

No new imports or non-YAML changes are necessary.

---

To fix the problem, add a permissions block at the top/root level of the workflow YAML to explicitly restrict the permissions of the GITHUB_TOKEN. The minimal change is to add permissions: contents: read immediately after the name field (line 1), before on: (line 3). This grants read-only access to the repository contents, which is usually sufficient for workflows that only need to clone code and do not push changes, create releases, or other write actions. If the workflow later needs additional permissions, they can be added in this block or at the job level. Only a single code change is required: addition of the permissions key.

To fix this, add a permissions key at the root of the workflow file (preferably just below the name: or on: keys) specifying the minimal necessary permissions for all jobs, or add a restrictive permissions key to each job as needed. If most jobs require only read access, use contents: read. If a job needs to write issues, pull-requests, or packages, grant that job only the required write permission (for example, the build job may need packages: write if it publishes NPM packages, but other jobs can remain read-only). As there’s no explicit evidence that any workflow step requires broader write access than publishing, the starting minimal block is:

permissions:
  contents: read

Add this block to the root of the workflow YAML file below the name: key (line 1), so it applies to all jobs unless overridden.

To resolve this issue, explicitly add a permissions block at the root of the workflow YAML file, right after the name: and before on: or jobs:. This will ensure that all jobs default to the specified minimal permissions unless a job specifies its own. As a starting point, set contents: read, which is generally sufficient for workflows that only need to check out code and read repository files. If specific jobs require higher permissions (such as publishing releases, creating tags, or managing PRs), those jobs should declare the additional permissions as needed.

File: .github/workflows/patch-functions-plugin-ci.yml
Region to edit: Insert a block after the name: line, before the on: block.
Permissions to set:

permissions:
  contents: read

To fix this problem, the workflow must have a permissions block set at the root (recommended unless individual jobs require dramatically different permissions), or per-job (for more granularity). For this workflow, since jobs such as check_file_changes and build do not seem to require broad write access (other than maybe releasing or publishing), the recommended starting point is:

permissions:
  contents: read

If jobs require additional privileges (such as pull-requests: write or packages: write for publishing), they can be added later if required—least privilege is key.

Implementation steps:

• Add a permissions block with contents: read at the top level, immediately below the name: field and before on:.
• If more privileges (e.g., for the publish job) are needed, extend the permissions, but only to the minimal set required.

There’s no need for external imports or new dependency installations for this edit, as it’s a YAML configuration change.

---

To fix this problem, add an explicit permissions: block at the workflow root (outside of the jobs: section, near the top of the file) to set least-privilege permissions for all jobs. For most CI workflows, setting contents: read is the minimum recommended, allowing jobs to access repository contents but not modify them.
If individual jobs require more permissions (like pull-requests: write or any other write access), add a more permissive job-scoped permissions: block there. Since we are only shown the top-level of the workflow, and the flagged error concerns absence of any permissions, the best approach is to add the top-level block:

• Edit .github/workflows/patch-ui-plugin-ci.yml
• Insert a permissions: block directly after the name: block and before on:
• Use:

  permissions:
    contents: read

• No other changes are needed, unless later jobs need more permissive scopes (not shown here).

---