ci: unified desktop build pipeline — renderer once, package in parallel

[huhuanming]

Summary

• Add build-desktop-renderer.yml: reusable workflow that builds the desktop renderer (webpack) once on ubuntu-24.04
• Add release-desktop-all.yml: orchestrator that calls the renderer build, then fans out to 3 platform packaging jobs in parallel

Pipeline architecture

renderer (ubuntu-24.04)        ← webpack build once
│
├─ package-mac (macos-26)      ← Phase 1: Mac DMG, Phase 2: MAS
├─ package-win (windows-2025)  ← Phase 1: Win NSIS, Phase 2: WinMS
└─ package-linux (ubuntu x2)   ← Phase 1: AppImage, Phase 2: Snap

Optimization

Metric	Before (5 separate workflows)	After (unified)
Renderer builds	5x	1x
yarn installs	7x	4x
macOS runners	2 jobs	1 job (mac + MAS)
Windows runners	2 jobs	1 job (win + winms)

Notes

• Additive only — existing per-platform workflows (release-desktop, release-desktop-win, etc.) are untouched
• Triggered via workflow_dispatch for now — can be wired to daily-build later
• Artifact names use onekey-desktop-all-* prefix to avoid collision with existing artifacts

Test plan

• Trigger release-desktop-all via workflow_dispatch
• Verify renderer artifact is created and downloaded by all 3 platform jobs
• Verify Mac DMG + MAS .pkg artifacts are produced
• Verify Win NSIS + WinMS .exe artifacts are produced
• Verify Linux AppImage + Snap artifacts are produced
• Compare output artifacts with existing per-platform workflow outputs

[revan-zhang]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scan Engine	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues
✅	Licenses	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

[socket-security]

Review the following changes in direct dependencies. Learn more about Socket for GitHub.

Diff	Package	Supply Chain Security	Vulnerability	Quality	Maintenance	License
	react-native-get-random-values@​1.1.46

View full report

[socket-security]

Warning

Review the following alerts detected in dependencies.

According to your organization's Security Policy, it is recommended to resolve "Warn" alerts. Learn more about Socket for GitHub.

Action	Severity	Alert  (click "▶" to expand/collapse)
Warn		Obfuscated code: npm @polkadot/util-crypto is 91.0% likely obfuscated Confidence: 0.91 Location: Package overview From: ? → npm/@polkadot/util-crypto@13.5.9 ℹ Read more on: This package | This alert | What is obfuscated code? Next steps: Take a moment to review the security alert above. Review the linked package source code to understand the potential risk. Ensure the package is not malicious before proceeding. If you're unsure how to proceed, reach out to your security team or ask the Socket team for help at support@socket.dev. Suggestion: Packages should not obfuscate their code. Consider not using packages with obfuscated code. Mark the package as acceptable risk. To ignore this alert only in this pull request, reply with the comment @SocketSecurity ignore npm/@polkadot/util-crypto@13.5.9. You can also ignore all packages with @SocketSecurity ignore-all. To ignore an alert for all future pull requests, use Socket's Dashboard to change the triage state of this alert.

View full report

In general, the fix is to explicitly define a permissions: block that grants only the minimal scopes needed for this workflow. Since the workflow only checks out code, uses GitHub Packages as an npm registry, and uploads artifacts, it needs read access to repository contents and packages, and does not need any write scopes.

The best fix here is to add a workflow-level permissions: block near the top of .github/workflows/build-desktop-renderer.yml (for example, after name: and before on:). This block will then apply to all jobs (including build-renderer) that do not override permissions. A suitable minimal configuration is:

permissions:
  contents: read
  packages: read

No other changes are required to existing steps or functionality, and no imports or external dependencies are involved.

In general, the fix is to add an explicit permissions: block that grants only the minimal scopes required for this workflow to run. For a release/build workflow that reads source and uses artifacts but does not push code or modify issues/PRs, contents: read is typically sufficient; if the workflow needs to download/upload artifacts only, that does not require extra scopes beyond contents: read. Because this workflow calls a reusable workflow (build-desktop-renderer.yml) and defines additional jobs, the safest and simplest change is to add a top‑level permissions: block so all jobs (including the called reusable workflow) default to least‑privilege settings.

Concretely, edit .github/workflows/release-desktop-all.yml near the top of the file, right after the on: block (line 10–18). Insert a root‑level permissions: section such as:

permissions:
  contents: read

This will apply to all jobs (including renderer, package-mac, and the other platform jobs) that do not override permissions. No imports or additional methods are required; this is purely a YAML configuration addition. If some unshown job genuinely requires write access in the future (for example to create releases), that job can override with its own permissions: while keeping the rest of the workflow restricted.

To fix the problem, explicitly define permissions for this workflow so that the GITHUB_TOKEN has only the minimal scopes required. Since the visible parts of this workflow merely check out code, download and upload artifacts, and access packages via NODE_AUTH_TOKEN (which uses secrets.GITHUB_TOKEN), contents: read and packages: read are sufficient as a safe baseline. These can be applied at the top (workflow) level so they affect all jobs, including renderer, package-mac, and the later package-win/Linux jobs referenced but not shown.

The single best minimal‑change fix is: add a workflow‑level permissions block just after the on: block (after line 18 and before the env: section). This sets default permissions for all jobs that do not override them, without modifying any job definitions or steps. No imports or additional methods are needed, since this is YAML configuration only. We do not change any existing behavior of the jobs; we only constrain the implicit token capabilities.

To fix the problem, explicitly declare a permissions block in the workflow so the GITHUB_TOKEN used in all jobs is restricted to the least privileges required. Since the workflow primarily checks out code, downloads/upload artifacts, and uses GITHUB_TOKEN as an auth token for package installation and build tooling, the minimal safe and generic setting is contents: read at the workflow level. This applies to all jobs that do not override permissions, including renderer, package-mac, package-win, and package-linux.

The best fix without altering functionality is to add a top-level permissions block just after the on: section (or immediately before/after env:) in .github/workflows/release-desktop-all.yml. This will not interfere with any secrets or steps and will simply constrain the automatically provided GITHUB_TOKEN to read-only repository contents, which is sufficient for actions/checkout, actions/download-artifact, actions/upload-artifact, and actions/setup-node with GitHub Packages. No additional imports or external dependencies are required.

Concretely:

• Edit .github/workflows/release-desktop-all.yml.

• Add:

  permissions:
    contents: read

  at the workflow root level (aligned with name, on, and env), between the existing on: block and the env: block (or just above jobs: if you prefer). No other lines need to change.

In general, you fix this by explicitly specifying a permissions: block either at the workflow root (to apply to all jobs that don’t override it) or per job, limiting the GITHUB_TOKEN to the least privileges needed. For this workflow, the jobs shown only need to read repository contents and possibly packages; they don’t push commits, create releases, or modify issues/PRs. Thus, a root-level permissions: block with contents: read is an appropriate minimal baseline. If the workflow also needs to read from GitHub Packages via the token, adding packages: read is also safe and minimal.

The single best fix without changing functionality is to add a root-level permissions: section just after the on: block and before env:. This will apply to all jobs (including package-linux at line 455 and the Windows/mac jobs referenced in the snippet) and satisfies the CodeQL requirement. The block should specify contents: read (and optionally packages: read if you want to be explicit for private registries). No additional imports, methods, or code changes are needed elsewhere, as this is purely a YAML configuration change.