Follow-up to #313128. The VSCODE_OSS fallback isn't needed for the
api.github.com calls in core-ci — secrets.GITHUB_TOKEN already
authenticates those reads with permissions: contents: read (added in
#304929), so we don't hit the anonymous rate limit on 1ES.
* ci: switch PR workflows back to 1ES self-hosted runners with JobId
Re-applies #311975 (reverted in #312033). Adds per-run+attempt JobId
labels to scope 1ES agents to specific GitHub Actions runs and prevent
intermittent runner cancellations.
Also switches the pr.yml compile job's GITHUB_TOKEN from the
ephemeral repo-scoped runner token to secrets.VSCODE_OSS so cross-repo
GitHub API release fetches (vscode-js-debug, vscode-js-debug-companion,
vscode-js-profile-visualizer, etc.) authenticate properly. On 1ES pools
the shared egress IPs hit the anonymous 60/hr api.github.com rate limit
and produced 403 fan-out across PRs last time.
* ci: fall back to GITHUB_TOKEN for fork PRs
Match the historical pattern from before #255987 — fork PRs can't
access secrets.VSCODE_OSS, so use the conditional to pick GITHUB_TOKEN
for forks.
* Allow cherry-pick bot PRs in engineering system changes check
Add an exception for PRs created by vs-code-engineering[bot] whose title
starts with [cherry-pick] and that carry the cherry-pick-artifact label.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* Fetch cherry-pick-artifact label via API at runtime
The label is applied ~2s after PR creation, so the webhook payload may
not include it. Fetch current labels from the API instead, gated behind
cheap event-payload checks to avoid extra API calls on unrelated PRs.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* Add label retry loop and consolidate guard expressions
Retry the cherry-pick-artifact label check up to 3 times (2s apart) to
handle the ~2s delay between PR creation and label application.
Consolidate the repeated exception guards into a single 'allowed' step
with a 'blocked' output, simplifying downstream conditions.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
---------
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
The Electron main process intermittently crashes during startup on the
`[pango] FcInit` thread with a NULL pointer dereference in expat's XML
string processing, triggered by fontconfig parsing `<include>` directives
in fonts.conf via `XML_ExternalEntityParserCreate`.
Set FONTCONFIG_FILE to a minimal config based on upstream
fontconfig 2.15.0 fonts.conf.in with `<include>` directives removed and
generic family aliases inlined. This avoids the external entity parser
codepath entirely. A version check will fail the build once the runner
ships expat >= 2.7.5, prompting removal of the workaround.
* Bump version to 1.117.0
* npm i
* wait to do engine version bump
* Revert "wait to do engine version bump"
This reverts commit 9db1c0feb6.
* Add Copilot extension tests to Linux/Windows Electron integration test runs
* Remove failing step that we moved to the main build
---------
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
* ci: debug fontconfig crash during app launch
* chore: update commands
* ci: bump to ubuntu-24.04 to fix fontconfig crash
Fixes an intermittent SIGSEGV on the [pango] FcInit thread during
Electron startup in CI integration tests.
Root cause: Chromium's InitializeGlobalFontConfigAsync() posts FcInit()
to a thread pool worker (crbug.com/404311), while pango's pangoft2
backend independently calls FcInit() from its own thread during GTK
initialization. fontconfig 2.13.1 (shipped in ubuntu-22.04) lacks
thread-safe initialization — concurrent first-time FcInit() calls
race and both enter FcConfigParse(), corrupting shared global state.
This causes expat (called by fontconfig to parse fonts.conf) to
dereference a NULL pointer.
ubuntu-24.04 ships fontconfig 2.15.0 which includes the thread-safe
initialization from 2.14+.
* ci: enable namespace sandbox