Difference between revisions of "CBI"
(→Preferred Build Technologies)
|Line 71:||Line 71:|
==Preferred Build Technologies==
==Preferred Build Technologies==
* See [[Jenkins]]
Revision as of 07:27, 27 September 2018
The Eclipse Common Build Infrastructure (CBI) is an initiative combining infrastructure, technologies and practices for building Eclipse Software.
- 1 Jenkins @ Eclipse (JIPP)
- 2 CBI Goals
Jenkins @ Eclipse (JIPP)
Jenkins is a continuous integration (CI) server used on Eclipse servers for Eclipse projects as part of the Common Build Infrastructure (CBI). Jenkins instances are maintained by the Eclipse Webmasters/Release Engineer.
- List of Jenkins Instances Per Project (JIPP):
NOTE: JIPP instances are being migrated from a standalone implementation to a Kubernetes cluster implementation.
Each Eclipse Project has access to one Jenkins instance (JIPP), including the following:
- (1) Jenkins instance, with (1) resources Base 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.
- Access to worldwide download mirrors
Additional Resource Packs
Each Eclipse Project has access to one Base 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 Packs are only available to Enterprise and Strategic members.
- Enterprise and Strategic members can engage with the Foundation to acquire additional Packs.
Resource Packs Included in Membership
Eclipse Foundation Member Organizations have access to Resource Packs above the Base Pack that is allotted to each Project, based on their membership level.
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 <ember can assign several packs to a single project.
To assign a pack to a project, please file a Bug.
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
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 or code repositories.
Primary goals are:
- Make it really easy to contribute Eclipse projects
- Make it really easy to copy & modify source
- Make it really easy to build
- Make it really easy to test
- Make it really easy to post a change for review
- Make it really easy to sign software
Secondary goals are:
- Get all Eclipse projects building their software on Eclipse Foundation hardware.
- Make it easy for people to build custom Eclipse distributions.
Preferred Build Technologies
- We provide dedicated Jenkins instances to projects. See Jenkins.
- If you host your Eclipse project git repository at Github, we also support
- TravisCI. Not that this is for building only. We don't put any credential on TravisCI. If you need to publish to Maven Central, repo.eclipse.org, download.eclipse.org, ... you will need to do it from a dedicated Jenkins instance provided by the Eclipse Foundation.
- We do not support
If an environment is not listed in the unsupported list, you can ask whether it can be supported by opening a bug.
Maven 3.0 drives the builds. Projects are expected to provide standard Maven 3.0 POM files for their builds. The builds should be built in such a way that they can be run on the local workstation, or on the Eclipse build server. Note that builds can only be signed on the Eclipse build server.
- Parent Maven POM for Eclipse projects;
- Signing Builds using Maven; and
- Maven repository support at Eclipse.
Tycho is focused on a Maven-centric, manifest-first approach to building Eclipse plug-ins, features, update sites, RCP applications and OSGi bundles.
- Tycho project information, including demo projects; and
- Building Woolsey with Maven and Tycho
- Reference Card
- Packaging Types
p2 Repo checks
It's highly recommended that any Eclipse.org project runs frequently, and maybe even systematically, the p2 repo analyzer to make sure it conforms to some requirements of being a nice citizen in the Eclipse.org world.
Additionally to recommendation and infrastructure, the CBI also produces pieces of software that are meant to be commonly used by all Eclipse.org projects.
CBI License bundle
We offer a P2 repository containing the org.eclipse.license bundle which is located at:
This URL is a composite P2 repo containing the license bundle.
If you are using 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/manual.