Checkpoint Lab — Organization Folders, GitHub/GitLab/Bitbucket Discovery, Repository Onboarding, and Platform Automation

1. Scenario

You operate a Jenkins platform that should onboard only active, Jenkins-enabled repositories owned by approved engineering teams. You must prove why each repository is included or excluded, ensure generated children have no protected credentials by default, and handle repository removal predictably.

2. Baseline assumptions

• Jenkins 2.568.3 LTS, Java 21.
• Branch API 2.1280.v0d4e5b_b_460ef, Folders 6.1106.v3a_d9a_6d2465e.
• Mandatory path: local JSON provider simulation and local bare Git; no real provider credential.
• Optional provider baselines: GitHub Branch Source 1983.vfa_27ed961853, GitLab Branch Source 743.ve0c8154a_8da_b_, Bitbucket Branch Source 937.3.10.
• One disposable low-trust agent ch23-lowtrust; built-in node remains at zero executors.

3. Predict before changing anything

Write down two required predictions: (1) which repository IDs should be eligible from the checkpoint inventory; (2) which Jenkins child item should become orphaned after a provider removal. Also predict that no child can access a protected production credential because none is configured in this lab scope.

4. Checkpoint inventory

[
 {"id":201,"name":"orders","owner":"team-commerce","visibility":"public","archived":false,"jenkins":true},
 {"id":202,"name":"pricing","owner":"team-commerce","visibility":"public","archived":false,"jenkins":true},
 {"id":203,"name":"old-checkout","owner":"team-commerce","visibility":"public","archived":true,"jenkins":true},
 {"id":204,"name":"security-private","owner":"team-security","visibility":"private","archived":false,"jenkins":true},
 {"id":205,"name":"website","owner":"marketing","visibility":"public","archived":false,"jenkins":false}
]

Policy: allowed owner is only team-commerce; repository must be public, active and Jenkins-enabled. Therefore only IDs 201 and 202 should be onboarded.

5. Execute the deterministic discovery

Save the inventory to /tmp/ch23-checkpoint/repos.json, run a copy of the Chapter 23 discovery script with allowed={'team-commerce'}, and archive/retain the input and output. Create local bare repositories and disposable Multibranch children ch23-checkpoint/orders and ch23-checkpoint/pricing. Each child uses only ch23-lowtrust and archives its exact source SHA.

6. Verify predictions independently

7. Remove one repository

Delete ID 202 from the provider inventory, save a before/after diff, rerun discovery once, and preserve the new output. pricing is now an orphan candidate. Record its last source/build evidence, disable or retain it per the lab retention policy, and only delete it after the evidence packet is complete.

8. Optional real-provider validation

On a disposable provider organization you control, repeat the design with the exact branch-source plugin. Capture the app/token scope, organization/group ID, provider API quota headers, webhook registration, Organization Folder computation log and generated child names. Do not use broad organization-admin credentials or a production organization.

9. Required evidence packet

10. Cleanup and rollback

Remove only the disposable checkpoint folder, synthetic repositories, local provider files and lab agent created for this chapter. If you used an optional real provider, remove only the test webhook/app installation/credential after preserving its audit evidence. Never delete organization-wide hooks or credentials by pattern.

11. What Chapter 23 adds to the production operating model

Jenkins onboarding is now an explicit platform lifecycle: provider identity and API budget → repository discovery and ownership → generated child items → branch builds → webhook/status evidence → deterministic orphan retention. The next chapter moves from onboarding many repositories to reusing reviewed Pipeline behavior safely through Shared Libraries, versioned library code, resources and testing.

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.
• Branch API — version 2.1280.v0d4e5b_b_460ef; defines organizational folders, Multibranch children and event/computation logging.
• Folders — version 6.1106.v3a_d9a_6d2465e.
• Credentials — version 1511.v2e3cb_0008ef0.
• GitHub Branch Source — version 1983.vfa_27ed961853, requiring Jenkins 2.541.1.
• GitLab Branch Source — version 743.ve0c8154a_8da_b_, requiring Jenkins 2.504.3.
• Bitbucket Branch Source — version 937.3.10, requiring Jenkins 2.541.3.
• GitHub REST API rate limits — authenticated users normally receive 5,000 requests/hour; GitHub App installation limits vary and include higher Enterprise Cloud allowances.
• GitLab.com rate limits — authenticated limits are plan-dependent; self-managed limits can differ.
• Bitbucket Cloud API request limits — authenticated and anonymous requests have separate rolling limits.

Version note — 2026-09-17: mandatory exercises are a local faithful simulation and require no external SCM account. The optional real-provider path must re-check the exact provider plugin version, security advisories, API permissions, webhook behavior, rate-limit headers and provider-plan limits before use. Never substitute a broad personal/admin token merely to make discovery easier.