Skip to content

Welcome to the Eclipse Foundation Common Build Infrastructure (CBI) Blog

RSS logo Subscribe to RSS feed

GitHub/GitLab: Decision Matrix Part 1 - Understanding CI Differences

The Eclipse Foundation gives projects the freedom to choose between GitHub and GitLab for hosting and managing their source code.

While both platforms are built on the same underlying Git technology, their platform approach brings a range of additional features. Some of these features overlap, addressing common project needs (with subtle implementation differences), while others take entirely different approaches.

What This Blog Post Series Will Cover

The next blog posts will dive into these differences, with a purely technical focus for developers, DevOps engineers, and infrastructure teams. The goal? Highlighting key differences in approach, implementation, and alternative services provided by the Foundation.

We will cover the following topics in the next blog posts:

  • CI pipelines (GitHub Workflows, GitLab Runners)
  • Runner management and execution environments
  • Quota models and build resource allocation
  • Additional build-related services

What This Blog Post Series Will not Cover

To keep things focused and digestible, we won’t be covering broader topics such as:

  • Project visibility/SEO
  • Data sovereignty and compliance
  • Community engagement and contribution models

While these are critical considerations when selecting a platform, they deserve their own dedicated posts.

Before we jump into the details, it’s important to note that the versions of GitHub and GitLab offered by the Eclipse Foundation are enterprise-grade:

  • GitHub Enterprise
  • GitLab Ultimate

This is crucial because these versions unlock advanced features, such as extended security options; extra build times, that are not available in the public/community versions.

GitHub Actions, GitLab CI, and Jenkins

GitHub Actions and GitLab CI are very similar in structure, syntax, and functionality:

  • In both cases, CI/CD configuration files are written in YAML and stored closed to the code in the Git repository.
  • Both are event-driven and get triggered by pushes, PR/MR, tags, issues, or on a schedule.
  • Tasks can be defined in stages (e.g. build, test, publish, deploy).
  • Both allow templating or re-use of tasks.
  • Both feature plenty of integrations (via the GitHub Marketplace or GitLab CI extensions). While the GitHub Marketplace has more actions, GitLab has built-in security and governance checks.

At the end of the day, it’s a matter of preference. For most common CI tasks, both systems are equally easy to write, maintain, and execute. Implementing specific use-cases can require more in-depth knowledge and might have a steep learning curve.

The Eclipse Foundation also offers a fully managed Jenkins instance for every project. It easily integrates with either GitHub or GitLab and provides an additional CI/CD approach. Jenkins can be used instead of GitHub actions or GitLab CI, but also in combination with each respective system. Due to its plugin-based structure, many scenarios can be covered.

Who Manages the Runners?

GitLab CI relies on dedicated runners, deployed and managed by the Eclipse Foundation Releng team. Runners are provisioned with GRaC (GitLab Runner as Code) and all requests for GitLab CI require a Helpdesk ticket so that the Releng team can provision and configure runners.

Standard GitHub runners offered to public projects for free do not require maintenance from the Releng team. Larger and more powerful GitHub runners can be set up on demand with sponsoring from eligible Eclipse member organizations.

Where Are My Builds Running?

The Eclipse Foundation’s build infrastructure is running on an OKD Kubernetes cluster (the upstream community project of OpenShift) on-premises.

GitLab CI/CD runners and Jenkins builds are executed within the Eclipse Foundation’s build cluster, located in Canada. GitHub Actions runners, run on GitHub’s cloud infrastructure.

The infrastructure where the runners are executed is essential because, as we will see later, it can have security implications depending on the measures implemented within these environments.

External Runners

Projects can ask to connect their own runners when they need:

  • Higher performance (more CPU/RAM) than default runner configuration can provide
  • Custom execution environments: RISC-V, ARM, ...

This requires a Helpdesk ticket and approval from the Eclipse Foundation security team.

Next posts

That wraps up this first article! In future posts, we will cover:

  • Resource Quotas
  • Build images
  • Secrets management
  • Hosting static website
  • Advanced security policies

Develocity Evaluation Phase: Presentation with Gradle on Optimizing Pipelines for Eclipse Projects

The Eclipse releng team is currently evaluating throw the Develocity staging instance the relevance of the Develocity platform by Gradle Inc in understanding and optimizing their pipelines.

On Thursday, February 6, a dedicated presentation was held in collaboration with Gasper Kojek from Gradle to explore the platform's capabilities and discuss how it could benefit both Eclipse projects and the releng team in addressing build challenges.

The session focused on the challenges, the evaluation phase, Develocity’s features and how it could enhance build performance, visibility, and reliability across Eclipse projects.

🎥 Watch the Presentation

Watch the Presentation

Please find below a summary from this session.

1. Challenges in CI/CD for Eclipse Projects

Eclipse projects face several build-related challenges, including:

  • Slow Build Identification: Detecting bottlenecks in pipelines is difficult without proper monitoring.
  • Limited Build Performance Visibility: Internal metrics (CPU, RAM, network usage) are not widely accessible, making debugging harder.
  • Build Failures & Flakiness: Unstable builds reduce trust in CI services and require significant debugging effort.
  • Infrastructure Constraints: Projects operate in a shared environment with limited resources, requiring efficient caching, parallelization, and optimization to maintain performance without increasing infrastructure costs.

Projects need pipelines that are Fast, Safe, and Reliable.

2. Develocity Evaluation Phase

The evaluation phase of Develocity started in January and runs until March, with a possible extension to June.

Post-Evaluation Goals:

  • Community Feedback: Assess Develocity's value through user input and surveys.
  • Infrastructure Impact: Evaluate impact on storage, CPU, and memory usage. And assess the effort needed to maintain Develocity operationally.

3. What is Develocity?

Develocity is a data platform & acceleration engine designed to improve developer productivity by providing insights into CI builds and enabling faster, more reliable builds.

3.1 Build Insights (Build Scans)

  • Provides detailed build reports (dependencies, executed tasks, system metrics).
  • Allows failure debugging through deep log analysis.
  • Helps track long-term build performance trends.
  • Supports Maven, Gradle, Bazel, SBT, NPM, Python, and Tycho (support in progress).

3.2 Build Acceleration Technologies

  • Build Caching: avoids redundant work by reusing previous results.
  • Predictive Test Selection: Uses machine learning to run only relevant tests.
  • Test Distribution: Distributes tests across multiple agents for faster execution.

3.3 Real-world Example:

  • Eclipse Store project reduced build time from 11 minutes to 50 seconds using build caching.
  • Eclipse Jetty tests went from 47 minutes to 16 minutes with test distribution.

4. Live Demo Highlights

  • Develocity Dashboard: Showed CI performance metrics, failure rates, and test flakiness.
  • Dependency Resolution View: Helped track package versions and transitive dependencies.
  • Flaky Test Analysis: Identified test inconsistencies across multiple CI runs.
  • Performance Optimization: Demonstrated time saved by caching and test parallelization.

5. Key Takeaways:

  • Develocity provides better CI visibility and performance optimization.
  • It helps reduce build times, improve reliability/consistency, and optimize resource usage.
  • The evaluation phase is ongoing, and projects are encouraged to participate.

How to Join the Develocity Evaluation Phase?

Create a HelpDesk ticket to onboard your project.

Additional Resources:

  • in CBI
  • 1 min read

Welcome to the first post of the CBI blog

Here is a short overview of what we are planning to do with this blog and CBI in general in 2025.

Continuous Blogging Initiative

One of our annual objectives is to improve communication about CBI and Release Engineering (Releng) topics. The CBI blog is an important part of this objective and should give our community more insight into what has happened and what will happen in the future in “releng land”. It will involve a good amount of “learning on the job” and we will adjust content and technical details as we see fit.

The current plan is to have:

  • One blog post per month (schedule: TBD)
  • Topics: status updates, road map insights, best practices, technical details

CBI in general

Our three main objectives for 2025 are:

  • More monitoring
  • Modernizing releng services
  • Enhance communication

We already mentioned enhanced communication above, and you are currently reading one of the results. Another step stone for better communication is a central page for CBI related topics that should make it a lot easier for everyone to find information and documentation that is distributed across multiple locations. This central page can be reached at https://eclipse.dev/cbi and its sources can be found at https://github.com/eclipse-cbi/cbi-website.

We will talk more about monitoring and modernization in future blog posts

Back to the top