Study Guide: Migrating Actions, Secrets, and Runners

This guide covers the technical and strategic transition of CI/CD assets within the GitHub ecosystem. It focuses on maintaining uptime and security during the move.

The Analogy: Moving a Professional Kitchen

Think of migrating GitHub Actions like moving a high-end restaurant to a new city. The Workflows (YAML) are your recipes—they tell you what to do. The Runners are your appliances (ovens, stoves)—the physical infrastructure where the work happens. The Secrets are your fresh ingredients—highly perishable and sensitive. You can pack the recipes easily, but you can’t “move” a lit flame or an open gallon of milk. You have to set up new appliances in the new location and source fresh ingredients (re-key secrets) to ensure the kitchen stays functional and safe.

Core Concepts & Terminology

1. Workflow YAML & Actions

The logic of your CI/CD. Migrating involves updating uses: tags, ensuring action versions are pinned (SHA vs. Tag), and adjusting on: triggers to match the new repository structure.

2. GitHub Secrets & Variables

Secrets are write-only. You cannot “download” a secret from GitHub once it is set. Migration requires a source of truth (like HashiCorp Vault or 1Password) to re-populate the target repository using the GitHub CLI: gh secret set NAME -b"VALUE".

3. Runners (Hosted vs. Self-Hosted)

• GitHub-Hosted: Managed by GitHub, clean environment for every job.
• Self-Hosted: Managed by you. Migration involves installing the runner agent on your infrastructure and registering it with the new Org/Repo using a registration token.

Real-World Scenarios

Scenario 1: Solo Developer Moving to an Org

Context: A developer moves a side project into a professional GitHub Organization.

Application: The developer must move repo-level secrets to the Org level if they are shared, or use Environments to ensure the “Production” secret isn’t used during “Feature Branch” runs.

Why it works: It introduces professional governance. Risk: Forgetting to update the permissions: block in the YAML, causing the workflow to fail in the more restrictive Org environment.

Scenario 2: Large Enterprise Migrating from Jenkins

Context: 500+ pipelines moving to GitHub Actions.

Application: Using “Reusable Workflows” to create templates for Go, Java, and Node.js projects. Self-hosted runners are deployed via Kubernetes (Actions Runner Controller – ARC) to scale based on demand.

Why it works: Centralizes maintenance. Risk: “Workflow Sprawl” where every team writes their own custom actions, making security auditing impossible.

Interview Questions & Answers

1. How do you migrate secrets from one GitHub repo to another since they aren’t readable?

   You cannot read them via API. You must retrieve the values from your original Secret Store (Vault, AWS Secret Manager) and use the gh secret set command or the GitHub UI to recreate them in the target.

2. What is the security risk of self-hosted runners on public repositories?

   Untrusted code from a Fork PR could run on your private infrastructure, potentially accessing internal network resources or persistent data on the runner. Always use “Required Approval” for outside contributors.

3. When should you use an Environment Secret versus a Repository Secret?

   Environment secrets should be used for deployment credentials (e.g., PROD_AWS_KEY) to take advantage of protection rules like required reviewers. Repository secrets are for general CI tasks (e.g., Codecov tokens).

4. What is OIDC and why is it preferred for migrations?

   OpenID Connect allows GitHub Actions to communicate with cloud providers without long-lived static secrets. It uses short-lived tokens, making it more secure and easier to migrate than managing rotating keys.

5. How do you ensure a migrated workflow doesn’t break when a third-party Action updates?

   Pin the action to a specific commit SHA (e.g., actions/checkout@8ade135...) rather than a version tag like @v4, which can be moved.

6. What is the purpose of the permissions: key in a workflow?

   It follows the principle of least privilege, explicitly defining what the GITHUB_TOKEN can do (e.g., contents: read, pull-requests: write). Crucial when moving to Orgs with restrictive defaults.

7. How do you handle shared logic across 50 migrated repositories?

   Use Reusable Workflows stored in a central “devops-toolkit” repository. This allows you to update the logic in one place for all 50 repos.

8. What is the “Actions Runner Controller” (ARC)?

   An open-source Kubernetes operator that orchestrates and scales self-hosted runners automatically based on the number of pending workflows.

9. How do you debug a failing Action in a new environment?

   Enable “Step Debug Logging” by setting the secret ACTIONS_STEP_DEBUG to true, and check the “Runner Diagnostic Logs” for self-hosted infrastructure issues.

10. What are “Custom Properties” in GitHub and how do they help with Actions?

    They allow you to categorize repos (e.g., production: true). You can then use these properties to target specific runners or enforce specific workflow policies during migration.

Interview Tips & Golden Nuggets

Runner Comparison Table