Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

GitHub Actions infrastructure for testing #1053

Open
berquist opened this issue Mar 7, 2024 · 0 comments
Open

GitHub Actions infrastructure for testing #1053

berquist opened this issue Mar 7, 2024 · 0 comments
Assignees
Milestone

Comments

@berquist
Copy link
Member

berquist commented Mar 7, 2024

Autotester 2 will be based upon self-hosted GitHub runners. In order to support this we need to be able to build and test within a GHA-based environment in general. (Right now this is outsourced entirely to bare metal and VMs accessed through Jenkins.) To start with, we will use their free hosted runners with

  • Ubuntu 22.04 on x86_64
  • macOS 13 on x86_64
  • macOS 14 on M1
    We had a few internal discussions about costs of provided macOS runners. They are 100% free, even the ARM ones, just like the Linux ones. These are VMs, not containers; we may eventually want a Rocky-, UBI-, or Alma-based container as a free runner, but these will be covered by AT2-based self-hosted runners no matter what.

AT2 will not use labels to control whether or not it runs, but whether or not a PR is a draft. The basic setup using free runners should work this way too.

The lint checks also use labels for interacting with AT1. This will be replaced with calling the lint checks before running tests/AT2 and stopping the workflow using GH-provided built-in rules.

In order to migrate incrementally, all the new GH-provided infrastructure can be added without touching anything existing. For the formatting/lint checks, have https://github.com/pre-commit/action (not the provided service pre-commit.ci) run using https://pre-commit.com/, and only once this passes, start building and testing.


The setup for elements should look similar. There is an outstanding question about how to deal with the possible race that AT1 detects, where a commit is being made to core that would break an approved commit to elements and is not yet the HEAD of core that the elements commit sees. This is a problem that is more general than AT2 and requires further investigation. I don't expect it to need a complete redo of any initial work that doesn't account for repository synchronization.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants