GitHub user sshiv012 added a comment to the discussion: Adopt a UCI-sponsored self-hosted GitHub Actions runner
Hello Yicong, thank you for starting this discussion. I think a UCI-sponsored runner could be valuable, particularly for reducing queueing and making performance tests more reproducible. We operate something similar for Apache AsterixDB at UCI. A UCI-hosted Jenkins installation receives repository webhooks and can execute builds in parallel, reporting test results back to Gerrit (also UCI-hosted) as verification votes. AsterixDB uses Gerrit as its primary review system and mirrors the repository to GitHub, so the integration differs from Texera’s GitHub-centered workflow, but the operational experience is relevant: dedicated hardware gives us greater control over parallelism, installed software, caches, and performance-test conditions. For Texera, I would initially favor keeping GitHub Actions as the workflow and reporting layer and supplying ephemeral UCI-hosted Actions runners underneath it. Moving to a separate Jenkins controller would introduce another CI configuration, user interface, authentication model, and failure surface. Jenkins becomes more attractive if we later need capabilities that are difficult to express in Actions, for example, managing a pool of machines, scheduling long-running benchmark campaigns, or coordinating deployments to persistent testing environments. Jenkins also has support/integration with Github Actions. Some things worth noting would be - security issues : https://infra.apache.org/self-hosted-runners.html. ASF permits self-hosted Actions runners but explicitly warns about their security risks. Fork PRs should never execute on the UCI machines. Trusted jobs should also receive minimal credentials and run in disposable VMs or containers, with no access to UCI internal networks or the host. - staging env: The same UCI infrastructure could eventually support a shared Texera staging environment, which would be useful for integration testing and demonstrations. However, I would keep staging logically and operationally separate from CI runners. Machines that execute repository code should not share credentials, writable storage, or a network trust boundary with a persistent deployment. GitHub link: https://github.com/apache/texera/discussions/6973#discussioncomment-17817922 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected]
