Skip to content

Standardize org-level GitHub App and PAT usage across all repos #21

@kristopherjturner

Description

@kristopherjturner

Summary

Standardize GitHub authentication across the AzureLocal org so every repository uses the approved org-level GitHub App credentials and org-level PAT where required, and add an audit/remediation path to detect repos that are not using the standard.

Problem

We already know the approved authentication model:

  • GitHub App credentials at the org level
  • PAT at the org level for scenarios that still require PAT-based access

The gap is consistency.

Today the repos do not present a single clean standard:

  • current add-to-project.yml workflows use GitHub App secrets such as AZL_APP_ID and AZL_APP_PRIVATE_KEY
  • multiple setup and repo-management docs still describe ADD_TO_PROJECT_PAT as the required project auth secret
  • some repos may still depend on older PAT-only guidance or inconsistent secret setup
  • there is no org-wide audit that proves every repo is using the approved auth pattern

This creates drift, unclear onboarding, and avoidable failures when workflows depend on secrets that are missing or not standardized.

Current State

Observed examples:

  • platform and the shared _common template wire add-to-project.yml to AZL_APP_ID and AZL_APP_PRIVATE_KEY
  • several repo-management guides across repos still instruct maintainers to configure ADD_TO_PROJECT_PAT
  • the documented standard and the implemented workflow pattern are not fully aligned

Goal

Make sure every repo in the AzureLocal org is using the approved org-level authentication approach consistently.

That includes:

  • the approved GitHub App auth model
  • the approved org-level PAT where PAT is still required
  • shared secret names
  • shared reusable workflows where possible
  • validation that required secrets and workflow references are present in every target repo

Scope

  • inventory every repo in the AzureLocal org
  • identify where GitHub App auth is already used
  • identify where PAT auth is still required
  • identify repos that are missing the approved workflow/auth configuration
  • identify stale docs or templates that still describe the wrong auth approach
  • standardize workflow usage so repos consume the org-approved auth pattern
  • add an audit/report workflow to flag repos that drift from the standard

Proposed Approach

  1. Define the auth standard clearly
    Document which operations must use:
  • GitHub App auth
  • org-level PAT
  • built-in GITHUB_TOKEN
  1. Centralize reusable auth patterns
    Prefer reusable workflows or shared actions from AzureLocal/.github or platform so individual repos do not reinvent auth setup.

  2. Audit all repos
    Build a workflow or script that scans org repositories for:

  • required workflow files
  • required secret references
  • outdated PAT-only patterns
  • missing GitHub App integration
  • docs that conflict with the standard
  1. Remediate drift
    For repos not aligned with the standard:
  • open issues or PRs automatically, or
  • emit a report with exact fixes needed

Acceptance Criteria

  • A documented org standard exists for when to use GitHub App auth, PAT auth, and GITHUB_TOKEN
  • Every intended repo in the AzureLocal org is audited against that standard
  • Every intended repo uses the approved org-level GitHub App credentials where required
  • Every intended repo uses the approved org-level PAT where PAT is still required
  • Shared workflows/templates are updated to enforce the standard
  • Stale repo-management documentation is updated to match the actual standard
  • An automated audit can detect repos that are missing required auth configuration or are using deprecated patterns
  • The audit produces a clear remediation report

Notes

This should cover both workflow implementation and documentation consistency. Right now there appears to be a mismatch between current workflow usage and some of the repo setup guidance, which is exactly the type of drift this issue should eliminate.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions