Dashboard › publish › Distillation
3ab2f580-f852-41ed-9715-8261607de490["lore_tm_v1_V8r6T9JetZVCeiYiRw5OtQv4dsRxub_ByzhZ_vdAkhY","lore_tm_v1_IkaIWj0XJlafwaHg016nQRApcniasEvZvTXsfOVeaCo","lore_tm_v1_iF4CkgGOFaXCRFm6R2G9HL5ppfmZriyvom7JREf-x6Y","lore_tm_v1_UcCR0utPsUt-WyKyaS64WhTux1qiycgZCTwawiSTG3s","lore_tm_v1_dSl1h0O4GqzbwyvMArqN4hIyBMlk-fN6hoh-G8lDQic","lore_tm_v1_O6WUhK6FhW2_SdGDaDJGfj3AYnrEcM9cw40X1feT9wI","lore_tm_v1_dWTL0ESH-WqmCzj-0lgS-llgFmGwCS4jVSdIC2GcWcA","lore_tm_v1_QG-eJVA52d7Cfmebosh7c8WDGDiey5HQpv7PDiqbWAI","lore_tm_v1_u5GG-OuQxEs9xrou8qlDBsJwvGAC_t4whjsFjHS07RQ"]
Date: Aug 27, 2026
security-as-code repository should be locally accessible and may be checked out at ~/Code/getsentry/security-as-code.getsentry/publish release authorization model has no approver authorization check: adding or removing issue labels directly drives workflow execution. It stated it would map trigger paths and inspect security-as-code’s live schema and CI interfaces without exposing private configuration.ci-ready label after checking CI, including when ci-ready was already present.workflow_dispatch must always be allowed for manual recovery.auto-approve.yml at .github/workflows/auto-approve.yml is named auto-approve non-sdks; it triggers only on newly opened issues (issues.types: [opened]), with contents: read permission..github/workflows/auto-approve.yml runs auto-approve on ubuntu-latest only if github.actor is sentry-release-bot[bot] or getsantry[bot] and the issue title starts with publish: ..github/workflows/auto-approve.yml checks out only auto-approve-repos.txt using actions/checkout@v4, sparse-checkout: auto-approve-repos.txt, and sparse-checkout-cone-mode: false..github/workflows/auto-approve.yml obtains a GitHub App token using actions/create-github-app-token@v3, vars.SENTRY_INTERNAL_APP_ID, and secret SENTRY_INTERNAL_APP_PRIVATE_KEY; it sets GH_TOKEN, parses REPO from ISSUE_TITLE via sed -n 's/^publish: \(.*\)@.*/\1/p', and runs gh issue edit "$ISSUE_URL" --add-label accepted only when the parsed repository is an exact line in auto-approve-repos.txt..github/workflows/ci-poller.yml is named CI Status Poller; it runs on cron */5 * * * * and on workflow_dispatch with optional string input attempt, default "0"..github/workflows/ci-poller.yml uses contents: read and issues: read permissions. Its check-ci job runs on ubuntu-latest in production, gated by vars.CI_POLLER_HAS_PENDING == 'true' || github.event_name == 'workflow_dispatch', with concurrency group ci-status-poller and cancel-in-progress: false.ci-poller.yml creates two tokens: a sentry-internal-app token (vars.SENTRY_INTERNAL_APP_ID, secrets.SENTRY_INTERNAL_APP_PRIVATE_KEY) for label changes in getsentry/publish, which must trigger downstream publish.yml; and a release-bot token (vars.SENTRY_RELEASE_BOT_CLIENT_ID, secrets.SENTRY_RELEASE_BOT_PRIVATE_KEY, owner: getsentry) for cross-repository API access because the internal app is not installed on certain private repositories including sentry-xbox, sentry-playstation, sentry-switch, and service-registry.ci-poller.yml defines gh_api_release() to invoke gh api with RELEASE_TOKEN, capture stderr/stdout, emit ::warning::gh api failed: ... on nonzero exit, and return the API exit code; this allows cross-repo 404/API failures to be detected rather than treated as partial status data.ci-poller.yml polls only open publish issues with both ci-pending and accepted labels, up to 200, requesting JSON fields number,title,labels,body; it exits when none are found.ci-poller.yml parses GitHub repo as the initial owner/repo two segments from titles formatted publish: owner/repo[/path]@version, parses version, and skips malformed titles. It extracts a 40-hex commit SHA from a .../commit/{SHA}/checks/ URL in the issue body and skips issues with no matching SHA.ci-poller.yml resolves the release branch through repos/${repo}/commits/${issue_sha}/check-suites (.check_suites[0].head_branch // empty), then resolves current branch HEAD via repos/${repo}/git/ref/heads/${branch} (.object.sha); API/lookup failures are nonfatal and fall back to issue_sha. If HEAD differs, it replaces the SHA in the issue body through gh issue edit.ci-poller.yml fetches combined commit status from repos/${repo}/commits/${sha}/status and all paginated check runs from repos/${repo}/commits/${sha}/check-runs; it skips the issue on either API failure and also skips when both total_checks and total_statuses are 0, treating this as CI not yet started.ci-poller.yml: combined commit status must be success or there must be zero commit statuses; all check runs must be completed; and no completed check run may have a conclusion other than success, neutral, or skipped. It counts pending_checks where status != "completed" and unsuccessful_checks where a completed conclusion is not one of those three passing values.ci-poller.yml removes ci-pending, adds ci-ready, and comments: CI checks passed for ${repo}@${version}. Publishing is starting now. Because only ci-pending plus accepted issues are polled, adding ci-ready starts publishing.ci-poller.yml removes ci-pending and accepted, adds ci-failed, and comments with failed check names, SHA, a https://github.com/${repo}/commit/${sha}/checks/ link, and instructions to re-add accepted after CI is fixed. On commit-status failure with otherwise passing check runs, it makes the same label transition and comments with failed status contexts/links.ci-poller.yml cleanup always checks for remaining open issues labeled both ci-pending and accepted; using an app token from vars.CI_POLLER_APP_CLIENT_ID and secrets.CI_POLLER_APP_PRIVATE_KEY, it sets repository variable CI_POLLER_HAS_PENDING to "false" if zero remain and "true" otherwise.ci-poller.yml self-dispatches ci-poller.yml with incremented attempt when pending issues remain and token/check steps succeeded. It caps at 60 attempts (approximately 30 minutes), then relies on cron; comments state GitHub */5 cron can drift to 30–40 minutes, while self-dispatch normally yields roughly 30–60 seconds between checks, with concurrency limiting queued work to 1 running plus 1 queued./home/byk/Code/getsentry/security-as-code exists. Its top-level entries include .github/, CODEOWNERS, README.md, iac-security/, lib/, rbac/, pyproject.toml, requirements.d/, and sbin/.security-as-code/rbac/ contains Terraform RBAC configuration including terraform.tfvars, README.md, module/github/, module/group/, module/group-external/, module/group-ids/, module/terraformers/, env/prod/, env/prod-github/, lib/product-owners.yml, and GitHub/team-management tooling such as lib/github/team-member.py and lib/github/team-members-sync/teams.tf.security-as-code show GitHub-team Terraform configuration at rbac/module/github/team/main.tf, where role naming is github-${github_team._.slug} and github_team resource fields include name, privacy, and parent_team_id.security-as-code includes extensive production GitHub team declarations under rbac/env/prod-github/team/, including sdk-seniors.tf (SDK Seniors, parent engineering), team-javascript-sdks.tf (Team JavaScript SDKs, parent client-infra), team-mobile.tf (Team Mobile, parent client-infra), team-mobile-cross-platform.tf, team-mobile-core.tf, sdk-foundation.tf, security.tf, sre.tf, codeowners.tf, and many others; further search output was truncated after 100 matches.