Fork-Safe Salesforce Continuous Integration
Overview
Separate deterministic untrusted-code checks from credentialed org validation so pull requests cannot access Salesforce secrets or mutate a customer org.
Prerequisites
- Repository, Salesforce DX project, package layout, branch policy, and immutable dependency lock
- Synthetic metadata and API fixtures plus an authorized validation org
- CI, Salesforce admin, security, release, and code owners with environment protection rules
Tool Discipline
Use Read, Glob, and Grep to inspect approved repository and evidence files, WebFetch to re-check current first-party Salesforce documentation, and Write or Edit only for secretless plans, fixtures, configuration, and redacted receipts.
Current Contract
Salesforce CLI can validate and deploy source against authorized orgs, but exact commands, test levels, authentication, and metadata behavior vary with the pinned CLI and project. Fork pull requests must be treated as untrusted.
Authentication
Keep org authorization, certificates, secrets, and aliases out of fork-origin jobs, logs, caches, and artifacts. Resolve protected credentials only after trusted code, environment approval, and exact-head verification.
Instructions
- Pin runtime, package manager, Salesforce CLI, plugins, lockfiles, action SHAs, and generated-artifact checks.
- Create a secretless lane for formatting, linting, static analysis, unit tests, schema tests, fixture contracts, and source validation.
- Model auth expiry, permission denial, API-version drift, metadata conflict, partial deployment, limits, and rollback in fixtures.
- Restrict credentialed jobs to protected branches or environments with no fork secrets, minimal permissions, concurrency, and timeouts.
- Against an approved non-production org, verify identity, validate the bounded deployment, run required tests, and capture IDs.
- Require human approval and immutable artifact promotion before any production validation or deployment job.
- Reconcile deployed metadata and application health, publish a redacted receipt, and revoke temporary credentials.
Approval Boundaries
Do not expose secrets to pull requests, authenticate unreviewed code, auto-deploy to production, or lower required test levels or branch protection.
Output
Return the trust-boundary diagram, pinned CI configuration, secretless and protected gate results, org identity proof, validation IDs, promotion approval, and rollback evidence.
Error Handling
| Condition | Response |
|---|---|
| Fork job requests a Salesforce secret | Fail closed and keep the live-org lane skipped. |
| Validation org differs from the expected org | Stop immediately, revoke the session, and correct environment binding. |
| Protected validation is flaky | Fix determinism or quarantine the lane explicitly; do not silently make it optional. |
Example
A redacted completion receipt might look like this:
head=immutable; fork-lane=secretless-pass; protected-org=matched; validate=pass; tests=pass; production=manual
Resources
Next Steps
Run the workflow first in the lowest-risk authorized org and preserve its redacted receipt. Schedule a review against the next Salesforce seasonal release and the customer change calendar.