Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "CBI"
(→Preferred Build Technologies) |
|||
Line 1: | Line 1: | ||
− | The Eclipse Common Build Infrastructure (CBI) is an initiative combining infrastructure, technologies and practices for building, testing and delivering | + | The Eclipse Common Build Infrastructure (CBI) is an initiative combining infrastructure, services, technologies and best practices for building, testing and delivering software at the Eclipse Foundation. |
= Goals = | = Goals = | ||
Primary goals of the CBI initiative are: | Primary goals of the CBI initiative are: | ||
− | * Make it | + | * Make it easy for anyone to contribute to Eclipse projects. |
− | + | * Make it easy for projects to follow open governance and transparency best practices. | |
− | * | + | * Provide a set of industry-grade services (or integration with some widely adopted 3rd party services) for building and distributing Eclipse projects. |
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
= Asking for Help = | = Asking for Help = | ||
Line 21: | Line 14: | ||
= Service Level Agreement (SLA) = | = Service Level Agreement (SLA) = | ||
− | Most CBI services are Tier 2 - Best Effort, which means they are expected to be available at all times, and rapid restoration can be expected in the event of an outage. | + | Most CBI services are ''Tier 2 - Best Effort'', which means they are expected to be available at all times, and rapid restoration can be expected in the event of an outage. Eclipse Strategic Members can contact Webmaster in certain cases of off-hours support. |
Please see [[IT_SLA]] for more information on the Eclipse Foundation IT Services SLA. | Please see [[IT_SLA]] for more information on the Eclipse Foundation IT Services SLA. | ||
− | = | + | = Provided Services = |
== CI Environment (Jenkins) == | == CI Environment (Jenkins) == | ||
Line 31: | Line 24: | ||
We provide dedicated Jenkins instances to projects. See also [[Jenkins]]. | We provide dedicated Jenkins instances to projects. See also [[Jenkins]]. | ||
− | Jenkins is a continuous integration (CI) server used on Eclipse servers for Eclipse projects as part of the [[CBI|Common Build Infrastructure (CBI)]]. Jenkins instances are maintained by the Eclipse Webmasters/Release | + | Jenkins is a continuous integration (CI) server used on Eclipse Foundation servers for Eclipse projects as part of the [[CBI|Common Build Infrastructure (CBI)]]. Jenkins instances are maintained by the Eclipse Webmasters/Release Engineers. |
* List of Jenkins Instances Per Project (JIPP): | * List of Jenkins Instances Per Project (JIPP): | ||
− | ** https://ci.eclipse.org/ (standalone) | + | ** https://ci.eclipse.org/ (standalone / Kubernetes cluster) |
** https://jenkins.eclipse.org/ (Kubernetes cluster) | ** https://jenkins.eclipse.org/ (Kubernetes cluster) | ||
Line 159: | Line 152: | ||
{{important|Third party build services (e.g., Travis) limitations|The Eclipse Foundation's IT Team is responsible for the credentials (OSSRH, SSH and GPG keys...) it creates for projects. Keeping track of where credentials are disseminated is crucial for security reasons. As long as we have no automation in place to set/update/remove credentials on 3rd party build services, we don't put any credential on such services. For instance, it means that you can't use them to publish to Maven Central, or to upload build results to download.eclipse.org.}} | {{important|Third party build services (e.g., Travis) limitations|The Eclipse Foundation's IT Team is responsible for the credentials (OSSRH, SSH and GPG keys...) it creates for projects. Keeping track of where credentials are disseminated is crucial for security reasons. As long as we have no automation in place to set/update/remove credentials on 3rd party build services, we don't put any credential on such services. For instance, it means that you can't use them to publish to Maven Central, or to upload build results to download.eclipse.org.}} | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
== Docker Hub == | == Docker Hub == | ||
− | The Eclipse Foundation owns the [https://hub.docker.com/u/eclipse eclipse] organization at https://hub.docker.com. You can ask to get a repository being created on | + | The Eclipse Foundation owns the [https://hub.docker.com/u/eclipse eclipse] organization and a couple of other project specific organizations at https://hub.docker.com. You can ask to get a repository being created on one of these organizations. We will set permissions so that committers have write access to this repo (you will need to share your Docker Hub ID with us). |
We can also ask us to create a project specific organization. The organization name needs to follow the pattern ''eclipse<projectname>''. | We can also ask us to create a project specific organization. The organization name needs to follow the pattern ''eclipse<projectname>''. | ||
Line 191: | Line 161: | ||
Note that we don't grant admin permissions on any Eclipse Foundation owned organization. We recognize that this means that you will have to go through us for all new repo creation, but we can't grant organizations-wide admin permission assigned to committers for security reasons. | Note that we don't grant admin permissions on any Eclipse Foundation owned organization. We recognize that this means that you will have to go through us for all new repo creation, but we can't grant organizations-wide admin permission assigned to committers for security reasons. | ||
− | ==Nexus== | + | ==Nexus/Maven repository== |
See [[Services/Nexus]]. | See [[Services/Nexus]]. | ||
Line 197: | Line 167: | ||
==Signing tool== | ==Signing tool== | ||
− | * [ | + | * [https://git.eclipse.org/c/cbi/org.eclipse.cbi.git/tree/maven-plugins/README.md Maven plugins for signing artifacts] |
* [[IT_Infrastructure_Doc#Sign_my_plugins.2FZIP_files.3F|On demand signing tool]] | * [[IT_Infrastructure_Doc#Sign_my_plugins.2FZIP_files.3F|On demand signing tool]] | ||
− | = | + | ==Eclipse Platform / plugins specific tooling== |
− | + | ||
− | + | ||
− | == CBI license bundle == | + | === CBI license bundle === |
− | We offer a P2 repository containing the org.eclipse.license bundle which is located at: | + | We offer a P2 repository containing the `org.eclipse.license` bundle which is located at: |
http://download.eclipse.org/cbi/updates/license/ | http://download.eclipse.org/cbi/updates/license/ | ||
Line 212: | Line 180: | ||
This URL is a composite P2 repo containing the license bundle. | This URL is a composite P2 repo containing the license bundle. | ||
− | If you | + | If you use Tycho you can add the p2 repo to the <repositories> section of your pom.xml file. Something similar to this: |
<source lang="xml"> | <source lang="xml"> | ||
Line 237: | Line 205: | ||
</source> | </source> | ||
− | = | + | === p2 repo checks === |
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | == p2 repo checks == | + | |
A set of "tests" which create reports or can be ran as unit tests that check to correctness of p2 repositories. That is partially just "correctness" in general (such as, that jars are signed, etc.) but more so that repositories conform to the requirements of the Eclipse Simultaneous release (such as, that jars have correct "Provider names", licenses, etc.). For more information, see See [[CBI/p2repoAnalyzers/Repo Reports]]. | A set of "tests" which create reports or can be ran as unit tests that check to correctness of p2 repositories. That is partially just "correctness" in general (such as, that jars are signed, etc.) but more so that repositories conform to the requirements of the Eclipse Simultaneous release (such as, that jars have correct "Provider names", licenses, etc.). For more information, see See [[CBI/p2repoAnalyzers/Repo Reports]]. | ||
− | == p2 repo aggregator == | + | === p2 repo aggregator === |
A tool to combine several p2 repositories. Among other things, it makes sure they all have consistent constraints (that is, can be "installed together") unlike a raw p2 mirror task. For more information see [[CBI/aggregator]]. | A tool to combine several p2 repositories. Among other things, it makes sure they all have consistent constraints (that is, can be "installed together") unlike a raw p2 mirror task. For more information see [[CBI/aggregator]]. |
Revision as of 11:13, 11 July 2019
The Eclipse Common Build Infrastructure (CBI) is an initiative combining infrastructure, services, technologies and best practices for building, testing and delivering software at the Eclipse Foundation.
Contents
Goals
Primary goals of the CBI initiative are:
- Make it easy for anyone to contribute to Eclipse projects.
- Make it easy for projects to follow open governance and transparency best practices.
- Provide a set of industry-grade services (or integration with some widely adopted 3rd party services) for building and distributing Eclipse projects.
Asking for Help
- Need help actually building your code: ask your project mentors, or ask on the Common Build mailing list (cbi-dev). There are no dumb questions.
- Subscribe to cbi-dev here: https://dev.eclipse.org/mailman/listinfo/cbi-dev
Service Level Agreement (SLA)
Most CBI services are Tier 2 - Best Effort, which means they are expected to be available at all times, and rapid restoration can be expected in the event of an outage. Eclipse Strategic Members can contact Webmaster in certain cases of off-hours support.
Please see IT_SLA for more information on the Eclipse Foundation IT Services SLA.
Provided Services
CI Environment (Jenkins)
We provide dedicated Jenkins instances to projects. See also Jenkins.
Jenkins is a continuous integration (CI) server used on Eclipse Foundation servers for Eclipse projects as part of the Common Build Infrastructure (CBI). Jenkins instances are maintained by the Eclipse Webmasters/Release Engineers.
- List of Jenkins Instances Per Project (JIPP):
- https://ci.eclipse.org/ (standalone / Kubernetes cluster)
- https://jenkins.eclipse.org/ (Kubernetes cluster)
NOTE: JIPP instances are being migrated from a standalone implementation to a Kubernetes cluster implementation.
Requesting a JIPP instance
Please file a bug against Eclipse Foundation > Community > CI-Jenkins to request your project's own instance. Please ensure your project lead can +1 the request. Please specify if you wish to grant write access to your download area and/or code repositories.
What's provided?
Each Eclipse Project has access to one Jenkins instance (JIPP), including the following:
- (1) Jenkins instance, with (1) Resources Pack (see below)
- Membership-sponsored projects may allocate more resources (see below)
- Digital signing Service: Java JAR, Java Cryptography Extensions, Windows Portable Executable with Microsoft Authenticode, macOS application bundles.
- Packaging service: Apple Disk Image (.dmg), Linux Flatpak
- Disk space: Ephemeral for builds, permanent for release builds.
- (1) 1vCPU/3.75G/30G Linux Virtual Server (if needed) (courtesy of Microsoft Azure). Projects sponsored by Strategic Members can engage with the Foundation to get out of spec Virtual Server.
- Access to worldwide download mirrors
Additional Resource Packs
Each Eclipse Project has access to one Resources Pack for building. For some projects, that may not be enough. Projects sponsored by Eclipse Membership (via Project Lead) have additional Packs, based on membership level. These Packs can be allocated to projects.
- Some resources are only available to Enterprise and Strategic members.
- Enterprise and Strategic members can engage with the Foundation to acquire additional Packs.
Agent type | Linux (containerized, no root) |
---|---|
vCPU | 2 (burst to 4) |
RAM | 8GiB |
Disk | 50GB |
External slave support | Yes |
Agent type | Linux/Windows/macOS (VMs) |
---|---|
vCPU | 4 |
RAM | 8GiB |
Disk | 100GB |
Resource Packs Included in Membership
Eclipse Foundation Member Organizations have access to Resource Packs based on their membership level.
Not a member | Solution | Enterprise | Strategic | ||||
---|---|---|---|---|---|---|---|
— | [$0, $15k) | [$15k, $20k] | [$50k, $100k] | [$25k, $50k) | [$50k, $100k) | [$100k, $500k] | |
Resource packs | 1 | 1 | 2 | 4 | 3 | 5 | 10 |
Dedicated Agents | N/A | N/A | N/A | 0 | 0 | 0 | 2 |
Assigning Resource Packs to a Project
Resource Packs are assigned by Eclipse Members to Eclipse Projects they sponsor (Members have a Project Lead on the Project). Packs are assigned as a whole to a single project (i.e., can’t split Packs across multiple projects). A member can assign several packs to a single project.
To assign a pack to a project, please file a Bug.
CI Environment (Third-party)
If you host your Eclipse project git repository at Github, we also support some third-party services:
- TravisCI. TravisCI is free to use for open source projects, but you should be aware that it limits to 5 the number of executors per organizations. It means that only 5 builds can run concurrently in any organization. If your repositories are part of the Eclipse organization, you may face long delays between the trigger and the actually start of the job. If it's your case, and would like to stick to TravisCI for building, we suggest you ask to move to a dedicated organization.
We do not support
- CircleCI. https://circleci.com/
If an environment is not listed in the unsupported list, you can ask whether it can be supported by opening a bug.
Docker Hub
The Eclipse Foundation owns the eclipse organization and a couple of other project specific organizations at https://hub.docker.com. You can ask to get a repository being created on one of these organizations. We will set permissions so that committers have write access to this repo (you will need to share your Docker Hub ID with us).
We can also ask us to create a project specific organization. The organization name needs to follow the pattern eclipse<projectname>.
Note that we don't grant admin permissions on any Eclipse Foundation owned organization. We recognize that this means that you will have to go through us for all new repo creation, but we can't grant organizations-wide admin permission assigned to committers for security reasons.
Nexus/Maven repository
See Services/Nexus.
Signing tool
Eclipse Platform / plugins specific tooling
CBI license bundle
We offer a P2 repository containing the `org.eclipse.license` bundle which is located at:
http://download.eclipse.org/cbi/updates/license/
This URL is a composite P2 repo containing the license bundle.
If you use Tycho you can add the p2 repo to the <repositories> section of your pom.xml file. Something similar to this:
<repository> <id>license-feature</id> <url>http://download.eclipse.org/cbi/updates/license/</url> <layout>p2</layout> </repository>
In any particular feature which you need the license you can use the usual feature.xml section:
<?xml version="1.0" encoding="UTF-8"?> <feature id="org.eclipse.help" label="%featureName" version="2.0.0.qualifier" provider-name="%providerName" plugin="org.eclipse.help.base" license-feature="org.eclipse.license" license-feature-version="1.0.0.qualifier"/> ....
p2 repo checks
A set of "tests" which create reports or can be ran as unit tests that check to correctness of p2 repositories. That is partially just "correctness" in general (such as, that jars are signed, etc.) but more so that repositories conform to the requirements of the Eclipse Simultaneous release (such as, that jars have correct "Provider names", licenses, etc.). For more information, see See CBI/p2repoAnalyzers/Repo Reports.
p2 repo aggregator
A tool to combine several p2 repositories. Among other things, it makes sure they all have consistent constraints (that is, can be "installed together") unlike a raw p2 mirror task. For more information see CBI/aggregator.