| [cross-project-issues-dev] Gitlab runners are available for projects |
Hello,
We're thrilled to announce the addition of another string to our bow with a new powerful CBI (Common Build Infrastructure) feature: GitLab CI Runner Service powered by GRAC! (GitLab Runner As Code).
Give more CI choice to our Eclipse Projects
All Eclipse projects hosted on the Eclipse Foundation's GitLab instance (https://gitlab.eclipse.org) can now request this offering. This is a useful addition to our suite of services, by complementing the existing Jenkins build farm (https://ci.eclipse.org). It's a tailor-made approach that lets Eclipse Projects choose the CI path that aligns best with their vision and goals.
Industrialized GitLab Runner Service with GRAC!
The industrialization of GitLab runners is made possible by the creation of the GRAC! project. Just like its counterpart JIRO, GRAC! enables configuring runners as code and provisioning new instances for Eclipse Projects.
Many default parameters are already set to meet the requirements of the foundation's infrastructure. Additionally, projects can access “almost” all advanced runner features that can be adapted to suit needs according to the Eclipse Foundation policies.
Getting Started!
Request your first GitLab CI runner by opening a helpdesk ticket. The issue title should include the Eclipse Project's name, for example: “Requesting a GitLab CI Runner for project XXX”
Easy start with default pipeline template
If a project has not worked with GitLab CI before, we offer the opportunity to benefit from months of gained experience during internal testing. This comes in the form of accessible templates designed to facilitate the use of GitLab CI.
These templates offer the following options:
Default workflow definition
Code compliance: facilitated by tools like Reuse, DCO, and an ECA validation script.
Docker image building and publishing, integrated with the foundation's buildkit infrastructure.
GitLab's Auto DevOps tools integration.
Upload to download.eclipse.org.
…
All these templates are available within the GitLab project gitlab-ci-templates.
Feel free to use them and to contribute.
Potential of Auto DevOps:
GitLab Auto DevOps: Leveraging the power of GitLab Ultimate, Eclipse Projects can access some “Auto DevOps” features, enabling rapid and efficient application development, test and control. Please note that due to our infrastructure requirements in terms of security, some features are not available.
For Auto DevOps, the following features are not supported yet:
Auto Code Quality
Auto License Compliance (License scanning of CycloneDX files is supported on OpenShift)
Auto Browser Performance Testing
Auto Build
Operational Container Scanning (Note: Pipeline Container Scanning is supported)
Resource Pack and Sponsorship Reminder
Each eclipse project comes with one default resource pack allocated. It allows setting up either a Jenkins instance with a standard configuration (as detailed in the JIRO documentation), or now, a GitLab CI group runner with CPU, memory and concurrency default configuration.
To access more resource packs, Eclipse Project should seek sponsorship from Eclipse Foundation member organizations. Based on the sponsorship of these members, additional resource packs can be allocated.
Please refer to the resource pack documentation.
Feel free to explore our API to learn about the resource packs assigned to your Eclipse Project, as well as to discover the list of existing potential members who can sponsor.
Member Organizations Benefits
Sponsored Projects
Group runner
By default, the provided GitLab CI runners are group runners. This means that concurrent executions are shared among all GitLab projects within the group. However, it's important to highlight that Eclipse Projects have the flexibility to request runners specifically targeting a particular GitLab project, in accordance with the resource pack quota policy allocated to the Eclipse project. This allows to fine-tune runner resources according to needs, ensuring optimal performance and resource utilization.
Dedicated Runner Vs Shared Runner
Dedicated runners are exclusively available upon request and are aligned with the allocated resource packs. This approach ensures optimized resource allocation and efficiency. Shared runners will not be accessible as we prioritize infrastructure reliability.
Do You Want To Know More?
Full documentation is available in the GitLab Runner Service Documentation project.
It contains a service presentation, getting started section, some CI templates, a FAQ, useful links, and much more.