CI/CD

Deployment evidence turns "the errors started after a change" into a timestamped hypothesis. Use Jenkins for job and build history; use GitHub for pull-request intent, Actions runs and releases.

JenkinsCopy Anchor Link

Jenkins usually has one server per environment. reckon run jenkins picks the one for the active environment.

reckon run jenkins -- job list --recursive --status FAILURE -o json
reckon run jenkins -- build list <deploy-job> --limit 25 -o json
reckon run jenkins -- build get <job> <number> -o json
reckon run jenkins -- build stages <job> <number> -o json
reckon run jenkins -- build test-report <job> <number> -o json
reckon run jenkins -- build log <job> <number>

build list has no time flags: filter by the returned timestamps. Compare build start and end times with the alert, the error rate and the trace window. Build logs can confirm the deployed revision or show a failed rollout step.

GitHubCopy Anchor Link

The org folder is not a Git checkout, so pass --repo every time:

reckon run github -- pr list --repo <owner/repo> --search "merged:>=<date>" --json number,title,mergedAt,author,url
reckon run github -- pr view <number> --repo <owner/repo> --json title,body,files,mergedAt
reckon run github -- run list --repo <owner/repo> --workflow <workflow> --json databaseId,headSha,status,conclusion,createdAt,url
reckon run github -- release list --repo <owner/repo> --limit 10 --json tagName,publishedAt,name

Start with the window that matters, not the whole repository history.

Correlation checklistCopy Anchor Link

• Does the build or release timestamp precede the first bad metric?
• Was that revision actually deployed? A successful CI run is not proof.
• Do the affected traces exercise code the pull request changed?
• Did Kubernetes events or ECS service events show rollout instability?
• Does a rollback or a later build line up with recovery?