ci: port all GitHub Actions workflows to CircleCI [IDE-2497]

[basti-snyk]

Description

Implements IDE-2497 in full, per explicit follow-up direction: all four GitHub Actions workflows are ported to CircleCI with no functional changes (beyond the mandated AWS credential change below), and the GitHub Actions files are removed. This also incidentally implements the CircleCI-side mechanics IDE-2483 needs (OIDC-based S3 publishing), since it was blocked on this ticket and touches the exact same lines.

What moved (.circleci/config.yml):

• ci.yml → test-linux / test-macos / test-windows. Full 3-OS coverage restored/kept, replicating the original matrix's per-OS conditionals exactly: PMD lint (re-implemented via the PMD CLI + SARIF, since pmd/pmd-github-action is GitHub-Actions-only, with results still uploaded to GitHub's native code-scanning API so they show up the same way) + signed build + preview S3 upload only on the Linux leg on push to main; unsigned mvnw clean verify on all three OSes otherwise. (macOS/Windows do nothing on main pushes either — that's what the original matrix actually did, kept as-is.)
• release.yml → release workflow. No pipeline parameter to trigger it — it runs unconditionally on every pipeline (any branch) and always parks at an approve-stable-release approval job. To cut a release: open the CircleCI pipeline for whichever commit/branch you want to release from (main, or a hotfix branch — same flexibility GitHub's workflow_dispatch branch picker had) and click "Approve" on that job. Only then does the actual release job run (sign, tag, GitHub release, stable S3 upload).
• resource-check.yml → static-resource-check job, ported verbatim.
• readme-sync.yml → synchronize-readme job/workflows, ported verbatim (same Mon-Fri cron, plus a run_readme_sync parameter for the manual-dispatch equivalent).

AWS credentials — OIDC, not static keys, and treated as sensitive: Both S3 uploads (preview on main, stable in release) now use CircleCI's OIDC integration (circleci/aws-cli@5.4.1's aws-cli/setup + role_arn, verified with its own aws sts get-caller-identity step) instead of AWS_ACCESS_KEY_ID/AWS_SECRET_ACCESS_KEY. Per your feedback, no AWS configuration is hardcoded in config.yml — AWS_ROLE_ARN, AWS_REGION, and AWS_S3_BUCKET_NAME are all read from the CircleCI context at runtime.

Secrets / context needed in CircleCI (answering "how does upload work without secrets on main")

Create a context (I used the name snyk-eclipse-plugin-secrets in the config; rename to taste) with:

Variable	Used for	Notes
AWS_ROLE_ARN	OIDC S3 publishing (preview + stable)	arn:aws:iam::<account-id>:role/<role-name> — per IDE-2483 this should be the dedicated snyk-assets-eclipse-writer role reviewed there. Not a static credential — CircleCI exchanges its own OIDC token for short-lived STS credentials for this role, nothing long-lived is stored.
AWS_REGION	OIDC S3 publishing	e.g. us-east-1 (previously hardcoded in the YAML — moved into the context since all AWS config should be treated as sensitive).
AWS_S3_BUCKET_NAME	OIDC S3 publishing	unchanged from the existing GitHub Actions secret.
KEYSTORE, KEYSTORE_SHA, KEYSTORE_PASS	jar signing	unchanged from the existing GitHub Actions secrets.
GH_TOKEN	PMD SARIF upload, git push --tags + gh release create in release, readme-sync's clone/push/PR-create	new — GitHub Actions used its automatic per-run token for these; CircleCI has no equivalent, so this needs to be a real PAT. Needs repo + security_events scopes (classic PAT) or fine-grained equivalents (Contents: write, Pull requests: write, Security events: write on this repo; Contents: read on snyk/user-docs).

Apply that context to the test-linux, release, and synchronize-readme jobs/workflows (already wired up in the config). No job needs AWS_ACCESS_KEY_ID/AWS_SECRET_ACCESS_KEY at all anymore — this also happens to satisfy most of IDE-2483's "decommission static credentials" acceptance criteria on the code side.

CircleCI project settings will also need someone with the right permissions configured as an approver for the approve-stable-release job (CircleCI approval jobs are approvable by anyone with write access to the project by default; restrict further via CircleCI's project settings if a narrower approver list is required).

⚠️ Manual follow-up required (infra access I don't have from this sandbox)

1. Branch protection: main's required status checks almost certainly reference the old per-OS GitHub Actions check names and the now-deleted workflows. After this merges and the new CircleCI jobs have reported at least once, update Settings → Branches → main to require test-linux / test-macos / test-windows / static-resource-check (CircleCI) instead.
2. IDE-2483's role trust policy: I don't have access to snyk/polaris-terraform-layer-1-account to confirm which branches the snyk-assets-eclipse-writer role's trust policy allows. The assume-s3-writer-role command here runs unconditionally wherever it's called (main-branch preview upload, and the manually-approved release job) — if the role's trust policy is scoped to fewer/different branches than that, the aws sts get-caller-identity step will fail with an explicit AssumeRoleWithWebIdentity error, which is the safe failure mode, but someone with access to that repo should confirm the branch list matches before relying on this in production.
3. Decommissioning the static AWS key (IDE-2483): per its own acceptance criteria, order matters — verify a real OIDC publish succeeds first, then deactivate the old IAM access key, confirm publishing still works, then delete the key (and remove AWS_ACCESS_KEY_ID/AWS_SECRET_ACCESS_KEY from CircleCI project/context settings). None of that is something I can do from here.
4. I could not run circleci config validate against CircleCI's remote compile API, nor inspect the actual CircleCI run logs directly (network egress to circleci.com is blocked in this sandbox — connections reset at the TLS handshake). From the GitHub check-run summary (which I can read via the GitHub API even without CircleCI access) on a recent push: security-scans, static-resource-check, test-windows, and secrets-scan are passing; test-linux is very likely failing because the snyk-eclipse-plugin-secrets context doesn't exist in the CircleCI project yet; test-macos is also failing for a reason I couldn't diagnose without the actual job log (it doesn't use the context, so it's not the same cause as test-linux — if you can share that job's log output I can fix it directly).

Verification

• Ran an independent code-review pass twice on this diff (once on the initial 3-OS+release+resource-check+readme-sync port, once after fixing what it found) and fixed everything flagged, including two real bugs a live CircleCI run would have hit: the macOS Temurin checksum check was comparing against a filename that never existed (Adoptium's sidecar file names the original asset, not ours) and would have failed every test-macos run; and the PMD SARIF upload was missing checkout_uri, which would have made GitHub silently ignore the uploaded results.
• Locally verified: ./mvnw clean verify -DtrimStackTrace=false with JDK 17 (BUILD SUCCESS); downloaded and ran the exact pinned PMD 7.26.0 CLI against plugin/src/main/java with the repo's ruleset (13 violations, SARIF produced, jq count matches); the corrected checksum-verification logic.
• No sibling Snyk IDE repo (snyk-ls, vscode-extension, snyk-intellij-plugin, snyk-visual-studio-plugin) has an existing CircleCI build+test+release pipeline to replicate — they only run security-scans on CircleCI so far. cli was used as the executor-syntax reference for macOS/Windows/OIDC/approval gates.

Checklist

• Read and understood the Code of Conduct and Contributing Guidelines.
• Tests added and all succeed (CI-only change; verified the moved commands locally)
• Linted (YAML syntax checked)
• CHANGELOG.md updated (not user-facing) — n/a
• README.md updated (not user-facing) — n/a; RELEASE.md updated for the new CircleCI-triggered release flow and stable-release approval step

Screenshots / GIFs

N/A — CI configuration change only.

  

[snyk-io]

✅ 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
✅	Code Security	0	0	0	0	0 issues

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

[cursor]

/describe

[rrama]

One of my human's old CircleCI notes for this repo: they jotted down adding a manual approval step before the first S3 upload, just as a personal safety net for testing the initial cutover — not a hard requirement.