Critical changes coming to GitHub Actions: Ubuntu 24 migration guide

The looming change

On November 5, 2024, GitHub announced a significant change that will affect countless CI/CD pipelines worldwide: the migration of ubuntu-latest runners to Ubuntu 24. This isn't just another version bump – it's a fundamental shift in the GitHub Actions ecosystem that demands our attention.

Why this matters

Most developers treat CI/CD runners like black boxes. We write our workflows, they magically work, and we move on. But this approach is about to catch up with us. Between December 5, 2024, and January 17, 2025, GitHub will gradually migrate all ubuntu-latest workflows to Ubuntu 24, and here's the kicker: they're significantly trimming the pre-installed package list.

The great package purge

GitHub's decision to reduce the default package set isn't arbitrary. They're doing it to maintain their SLA for free disk space. However, the impact on existing workflows could be substantial. Here's what's getting axed:

Complete removals

• Development tools:

  • Heroku CLI
  • Leiningen
  • Mono/MSBuild/NuGet ecosystem
  • Terraform
  • R language support
  • SVN (because it's 2024, finally)

• Cloud provider tools:

  • Alibaba Cloud CLI
  • Netlify CLI
  • OpenShift CLI
  • Vercel CLI

• Rust ecosystem tools:

  • Bindgen/Cbindgen
  • Cargo audit/clippy/outdated

• Others:

  • MS SQL Server Client Tools
  • MarkdownPS Module
  • All cached Docker images (this one hurts)

Version changes that matter

More subtle but equally important are the version changes. Here are the most impactful ones:

Tool	Ubuntu 22.04 Versions	Ubuntu 24.04 Versions
Clang	13., 14. (default), 15.*	16., 17., 18.* (default)
GCC / G++ / GFortran	9., 10., 11., 12., 13.*	12., 13., 14.*
PHP	8.1.*	8.3.*
Java	8., 11. (default), 17., 21.	8., 11., 17.* (default), 21.*
Python	3.7., 3.8., 3.9., 3.10. (default), 3.11., 3.12.	3.9., 3.10., 3.11., 3.12. (default)
Go	1.20., 1.21. (default), 1.22.*	1.21., 1.22., 1.23.* (default)
Node.js	16., 18. (default), 20.*	16., 18., 20.* (default)
.NET Core SDK	6., 7., 8.*	8.*
PostgreSQL	14.*	16.*
Android NDK	25.* (default), 26.*	27.* (default), 26.*

Implication: Workflows depending on specific versions might encounter compatibility issues. For instance, if your application requires PHP 8.1.*, you need to ensure that the correct version is installed during your workflow.

💡 Check this GitHub issue for detailed changes.

What this means for you

1. Immediate actions required

If you're using ubuntu-latest, you need to:

• Audit Your Workflows: Before December 5, review every GitHub Actions workflow in your repositories.
• Check Package Dependencies: Compare your required packages against the removal list.
• Test on Ubuntu 24: Create a parallel workflow using ubuntu-24.04 to catch issues early.

2. Common pitfalls to watch for

• Docker Build Times: Without cached images, expect longer build times.
• Language Version Mismatches: Default versions are changing across the board.
• Missing Development Tools: Many previously available tools will need manual installation.

3. Migration strategies

The Safe Approach

name: CI
on: [push]
jobs:
  build:
    runs-on: ubuntu-22.04  # Pin to 22.04 temporarily
    steps:
      - uses: actions/checkout@v4
      # Your existing steps

The forward-looking approach

name: CI
on: [push]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      # Explicitly install removed packages
      - name: Install required packages
        run: |
          sudo apt-get update
          sudo apt-get install -y terraform
      # Your existing steps

Critical changes for self-hosted runners

New domain and IP requirements

One of the most significant changes affects organizations using self-hosted runners. GitHub is implementing stricter security controls that require explicit domain and IP permissions.

What's changing?

1. Domain Allowlisting: Self-hosted runners will need explicit permissions to communicate with specific domains.

2. IP Range Restrictions: Organizations must configure allowed IP ranges for runner communications.

3. Network Security: Enhanced security measures for runner-to-GitHub communications.

Required actions for self-hosted runner administrators

1. Domain Configuration

# Example organization-level configuration
runner-security:
  allowed-domains:
    - "*.github.com"
    - "*.actions.githubusercontent.com"
    - Your custom domains needed for workflows

2. IP range configuration

You'll need to allowlist these IP ranges in your network security groups:

• GitHub Actions service IP ranges

• GitHub API endpoints

• GitHub package registry endpoints

3. Security Best Practices

# Example workflow with runner security configurations
name: Secure CI Pipeline
on: [push]
jobs:
  build:
    runs-on: self-hosted
    permissions:
      # Explicit permission definitions
      contents: read
      packages: read
    steps:
      - uses: actions/checkout@v4
      # Your workflow steps

Common pitfalls to avoid

1. Incomplete Domain Lists: Missing domains can break package downloads and external service integrations.

2. Over-permissive IP Ranges: Avoid using broad IP ranges; be specific to maintain security.

3. Missing Authentication Contexts: Ensure proper authentication for all external service communications.

Webhook rate limiting

GitHub is also introducing new rate limits for webhooks, which affects how frequently your self-hosted runners can receive job notifications:

• Default rate: X requests per hour (adjust based on actual numbers)

• Burst limit: Y requests per minute

• Cool-down period: Z minutes

Migration checklist for self-hosted runners

1. Audit current configuration

   • Document all domains accessed by your workflows
   • List all required IP ranges
   • Review webhook usage patterns

2. Update network configurations

   • Configure firewalls and security groups
   • Update proxy settings if applicable
   • Test connectivity with restricted permissions

3. Monitor and validate

   • Set up monitoring for failed connections
   • Implement logging for security-related events
   • Create alerts for rate limit warnings

4. Documentation updates

   • Update runner setup documentation
   • Document new security requirements
   • Create troubleshooting guides

Looking forward

This change signals a broader trend in CI/CD: the move toward more explicit dependency management. While it might seem inconvenient now, it's pushing us toward better practices:

1. Explicit Over Implicit: Declaring all dependencies makes workflows more portable and maintainable.
2. Container-First Thinking: Using container-based workflows reduces runner dependencies.
3. Version Pinning: Being explicit about tool versions reduces "it works on my machine" issues.

Action items

1. Mark December 5, 2024, in your calendar.
2. Audit your GitHub Actions workflows this week.
3. Test your critical workflows on Ubuntu 24.
4. Update your dependencies management strategy.
5. Consider pinning to ubuntu-22.04 temporarily if you need more migration time.

Additional action items

1. Document all external service dependencies for self-hosted runners
2. Update network security policies
3. Configure webhook rate limit monitoring
4. Test runners with restricted permissions
5. Create a rollback plan for critical workflows

Security considerations

The new self-hosted runner requirements reflect GitHub's commitment to enhanced security. While these changes may require additional configuration, they provide:

• Better isolation between runners and external services
• Clearer audit trails for runner activities
• Reduced risk of unauthorized access
• Improved compliance with security standards

Remember: Security should never be an afterthought. These changes force us to be explicit about our security boundaries, which is ultimately a good thing for our CI/CD infrastructure.

The silver lining

While this change might seem disruptive, it's an opportunity to make our CI/CD workflows more robust. By forcing us to be explicit about our dependencies, GitHub is actually pushing us toward better DevOps practices.

Remember: The best time to prepare for this change was when it was announced. The second best time is now.

---

For more tips and insights, follow me on Twitter @Siddhant_K_code and stay updated with the latest & detailed tech content like this.