Checkpoint Lab — Multibranch Pipelines, Branch Sources, Pull Request Discovery, Jenkinsfile Trust, and Branch Indexing

1. Scenario and success criteria

You own a small internal CI platform. Developers want automatic branch builds, but external-style contributions must never gain deployment secrets or privileged agents. Your checkpoint is to create a local synthetic Multibranch project, capture indexing/source evidence, model an untrusted contribution, and show that the lab exposes no protected secret. You will then state which provider trust controls a production fork-PR workflow still requires.

2. Reproducible assumptions

3. Preflight

Before creating or rescanning anything, record:

• controller URL, Jenkins/Java/plugin versions;
• agent name/label/executor and trust classification;
• that the built-in node has no executor for untrusted builds;
• the synthetic remote path and its current branches/SHAs;
• the intended orphaned-item retention values;
• the fact that no registry/cloud/signing/production credential is available to this project.

4. Write predictions before execution

Write at least these predictions in your notes:

1. Initial indexing will create child jobs for main, feature-safe and pr-untrusted.
2. Each child build will archive a source SHA matching its branch head and a branch-specific Jenkinsfile marker.
3. After deleting feature-safe and rescanning, Jenkins will apply the configured orphaned-item policy rather than silently rebuilding it.
4. An attempt by pr-untrusted to bind ch22-protected-simulation cannot reveal a protected value because no such credential is present.

5. Execute the checkpoint

Repeat the Lesson 2 synthetic-repository creation and create ch22-multibranch. Preserve the first branch-indexing log. Build all discovered children once. For each build, archive source-sha.txt and jenkinsfile-marker.txt and record BRANCH_NAME, build number/URL, node, workspace and source SHA.

Then change only the pr-untrusted Jenkinsfile to request a nonexistent fake credential:

stage('Protected capability probe') {
  steps {
    withCredentials([string(credentialsId: 'ch22-protected-simulation', variable: 'PROTECTED')]) {
      sh 'echo this-line-must-never-run'
    }
  }
}

The failure is intentional. Do not “fix” it by creating a real or fake reusable secret. Preserve the error showing the credential could not be resolved. The point is that untrusted candidate code received no protected value.

6. Prove the agent/secret boundary—and its limitation

Verify the build ran only on the disposable ch22-untrusted worker. Confirm there are no configured protected credentials in the project/folder scope used by the checkpoint and no sensitive artifacts/environment dumps in the build record.

7. Provider-production proof plan

Without connecting a real account, write the provider proof you would require before production:

• provider branch-source plugin and exact version/advisory review;
• fork/PR discovery trait and trust strategy;
• evidence of candidate revision versus trusted revision/Jenkinsfile source;
• untrusted jobs mapped to non-privileged agents with no protected credentials;
• post-merge/release job using a trusted revision for protected deployment;
• provider event/webhook audit ID and Jenkins indexing/build cause correlation.

8. Orphan and retention test

Delete feature-safe from the bare remote, preserve the remote branch list, then run one branch index. Capture the indexing lines that report the missing/orphaned head and verify the resulting child-job behavior matches your recorded retention policy. Do not manually delete the child before this check.

9. Required evidence packet

10. Cleanup and rollback

After exporting the evidence packet, remove only the disposable ch22-multibranch parent, synthetic repository, mount and lab agent created for this chapter. Restore any lab-only retention/executor setting you changed. Do not delete unrelated Jenkins items, provider hooks or credential stores.

11. What Chapter 22 adds to a production operating model

Jenkins can now create jobs automatically from SCM heads without losing provenance: you can identify the branch-source plugin/version, repository, discovery traits, indexing event, candidate/trusted revision, Jenkinsfile path, child job, build/source SHA, credential/agent trust boundary and orphaned-item policy.

Chapter 23 expands this one-repository automation into Organization Folders that discover many repositories across GitHub, GitLab or Bitbucket. The same lessons become more important because repository onboarding, credentials, indexing load and trust are multiplied across an organization.

Knowledge check

Answer before revealing the explanation.

Official references and version notes

• Jenkins LTS changelog — chapter baseline Jenkins 2.568.3 LTS, released 2026-09-02 and tested with Java 21 and 25; labs use Java 21.
• Jenkins: Branches and Pull Requests — Multibranch discovery, branch child jobs, indexing and change-request environment variables.
• Pipeline: Multibranch — version 841.vec5b_9e1806ec, requiring Jenkins 2.504.3.
• Branch API — version 2.1280.v0d4e5b_b_460ef; documents Multibranch event/indexing log locations and routing.
• SCM API — version 728.vc30dcf7a_0df5.
• Git plugin — version 5.10.1.
• Git Client plugin — version 6.6.1; current releases include fixes for earlier command-injection issues on agents.
• GitHub Branch Source — provider-specific optional reference, version 1983.vfa_27ed961853, requiring Jenkins 2.541.1.
• Pipeline: Multibranch step/reference — documents provider pull-request trust strategies and trusted-file behavior.
• Credentials API — version 1511.v2e3cb_0008ef0; credentials remain a separate authorization boundary from SCM discovery.

Version note — 2026-09-17: executable local examples assume Jenkins 2.568.3 LTS, Java 21, Pipeline: Multibranch 841.vec5b_9e1806ec, Branch API 2.1280.v0d4e5b_b_460ef, SCM API 728.vc30dcf7a_0df5, Git 5.10.1, and Git Client 6.6.1. GitHub Branch Source 1983.vfa_27ed961853 is used only to explain a real provider fork/PR trust model; the mandatory local lab does not require an external SCM account or real SCM credential. Re-check provider plugin advisories and trust semantics before production adoption.