VID-10459: Replace GitLab CI pipeline with GitHub Actions

[znorris]

I'm replacing the GitLab CI pipeline with GitHub Actions and deleting .gitlab-ci.yml. There were no other .gitlab/ fragments to remove.

What each job became

test and lint (both stage: test in GitLab) are now separate jobs in .github/workflows/ci.yml, each running its own bundle install against the shared vendor/bundle cache, same as before. lint keeps continue-on-error: true in place of allow_failure: true; I confirmed locally that rubocop currently reports 166 offenses against this repo's empty .rubocop.yml, so it has to stay non-blocking. Both jobs run in a ruby:3.4.5 container rather than via ruby/setup-ruby, because this repo's Actions policy is allowed_actions: "selected" and that action isn't on the allow-list; pulling a plain image needs no allow-listing and mirrors GitLab's own image: mechanism. JUnit output that GitLab ingested natively is now uploaded as a plain artifact, since Actions has no equivalent report ingestion.

The pages job (stage: deploy) became .github/workflows/pages.yml, split into build and deploy per GitHub's Pages model. I trigger it off workflow_run of the CI workflow rather than independently on push, so build only starts once CI has completed for the same commit and only proceeds if it succeeded, reproducing GitLab's stage ordering (stage: deploy only started once every stage: test job succeeded; lint's allow_failure: true meant it never blocked that gate). build checks out github.event.workflow_run.head_sha rather than the branch tip, so it builds the exact commit CI tested. pages: write and id-token: write are scoped to the deploy job only, not the workflow level, so build, which runs bundle install against a lockfile-resolved dependency tree, never holds either scope.

Behavior that deliberately differs from GitLab

push is scoped to main, and pull_request covers everything else. This avoids GitLab's duplicate pipelines, where a push to a branch backing an open merge request produced two runs for the same commit (if: $CI_COMMIT_BRANCH OR if: $CI_PIPELINE_SOURCE == "merge_request_event", with no dedupe). The cost is a gap GitLab didn't have: a commit pushed to a branch before any PR is opened for it runs no CI until a PR exists. I'm accepting this because it matches the trigger shape already established in sv-cloud's ci.yml.

kubernetes-operators-style container decisions don't apply here since there's no deploy job, but for completeness: this repo's test/lint/build jobs run in a bare ruby:3.4.5 container image rather than via a setup action, for the allow-list reason above, not for any security tradeoff.

What has to exist before this runs

This repo has never had GitHub Pages enabled (has_pages: false; GET /repos/ScoreVision/pug-client-ruby/pages returns 404). actions/deploy-pages calls the Pages Deployments API, which requires a Pages site already provisioned with build_type=workflow; it does not create one. Until a repo admin turns that on (Settings, Pages, Build and deployment, Source: GitHub Actions), the deploy job in pages.yml will fail even though build succeeds. ci.yml and the test/lint jobs have no external dependency and are runnable as soon as this merges.

[znorris]

These pages will be publicly accessibly. That won't leak any secrets. When we come up with something private, we'll move it over.

[znorris]

LGTM