Home
Jenkins is a continuous integration (CI) server. It is in use on Eclipse servers for Eclipse projects as part of the Common Build Infrastructure (CBI). This page is about the hosted service at Eclipse.org. For more information on the project itself, or to download Jenkins, please see the Jenkins project page.
Jenkins instances are maintained by the Eclipse Webmasters/Release Engineers.
- List of Jenkins Instances Per Project (JIPP):
- https://ci.eclipse.org/ (cluster-based infra)
- 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
Please file a HelpDesk ticket to request your project's own instance. Please ensure your project lead can +1 the request.
Integrating SonarCloud into a project's CI builds is quite easy. Please open a Bugzilla issue for this and the releng/webmaster team will help you set this up.
We're setting this up with the webmaster's SonarCloud.io account, so there is no need to provide a SonarCloud token. To avoid leaking the token in the console log, we store it as secret text (Jenkins credentials).
We will configure the SonarQube Jenkins plugin to use SonarCloud to achieve a slightly better integration with Jenkins. For example, a link to SonarCloud will show up in the left menu of a job page.
For a freestyle job configuration two things need to be done:
- Under "Build environment" enable "Use secret text(s) or file(s)", add "Secret text", name the variable "SONARCLOUD_TOKEN" and select the right credential (e.g. "Sonarcloud token").
- either a shell build step or a Maven build step can be used to run the sonar goal with the right parameters:
mvn clean verify sonar:sonar -Dsonar.projectKey=<project-name> -Dsonar.organization=<organization> -Dsonar.host.url=${SONAR_HOST_URL} -Dsonar.login=${SONARCLOUD_TOKEN}
For a pipeline job the following needs to be added:
withCredentials([string(credentialsId: 'sonarcloud-token', variable: 'SONARCLOUD_TOKEN')]) {
withSonarQubeEnv('SonarCloud.io') {
mvn clean verify sonar:sonar -Dsonar.projectKey=<project-name> -Dsonar.organization=<organization> -Dsonar.host.url=${SONAR_HOST_URL} -Dsonar.login=${SONARCLOUD_TOKEN}
}
}Please note: <project-name></project-name> and <organization></organization> should be replaced with the corresponding project name and organization.
In general, we want to avoid handing out admin rights in the future. At the same time, - in the spirit of configuration as code - we are planning to allow projects to submit pull requests to our Jiro repo and change the configuration of their CI instance. E.g. adding plugins, etc. This will allow better tracking of configuration changes and rollback in case of issues.
We understand that some projects heavily rely on their admin permissions. We will make sure to find an amicable solution in those cases.
The preferred way is to open a pull request in the Jiro GitHub repo. For example, to add a new plugin to the CBI instance, one would need to edit https://github.com/eclipse-cbi/jiro/blob/master/instances/technology.cbi/config.jsonnet and add the ID of the plugin to the plugins+ section. If the jenkins+/plugins+ section does not exist yet, it needs to be added as well.
Example:
{
project+: {
fullName: "technology.cbi",
displayName: "Eclipse CBI",
},
jenkins+: {
plugins+: [
"jacoco",
],
}
}
Only additional plugins that are not listed in https://wiki.eclipse.org/Jenkins#Default_plugins_-_Jiro_.28ci-staging.eclipse.org.2Fxxx_and_ci.eclipse.org.2Fxxx.29 need to be added to the config.jsonnet file.
The ID of a Jenkins plugin can be found here: https://plugins.jenkins.io/
If this sounds to complicated, you can also open a bug on Bugzilla.
The preferred static website generator for build Eclipse project websites is Hugo. You should first put your Hugo sources in a dedicated Git repository, either at GitHub if your source code is already hosted at GitHub or at git.eclipse.org. If you don't have such a repository already, feel free to open a request, the Eclipse IT team will create one for you.
Note that each and every Eclipse project automatically gets a Git repository with git.eclipse.org/www.eclipse.org/&lt;project_name&gt; (see this repository index for complete list). This is not where you want to push your Hugo sources. This repository contains the webpages that are automatically and regularly pulled and published on the www.eclipse.org HTTP server. All the content from the master branch will eventually be available at the URL https://www.eclipse.org/<project_name/>.
Once your Hugo sources are in the proper repository, create a file named Jenkinsfile at the root of the repository with the following content (don't forget to specify the proper value for PROJECT_NAME and PROJECT_BOT_NAME environment variable):
environment {
PROJECT_NAME = "&lt;project_name&gt;" // must be all lowercase.
PROJECT_BOT_NAME = "&lt;Project_name&gt; Bot" // Capitalize the name
}
triggers { pollSCM('H/10 * * * *')
}
options {
buildDiscarder(logRotator(numToKeepStr: '5'))
checkoutToSubdirectory('hugo')
}
stages {
stage('Checkout www repo') {
steps {
dir('www') {
sshagent(['git.eclipse.org-bot-ssh']) {
sh '''
git clone ssh://genie.${PROJECT_NAME}@git.eclipse.org:29418/www.eclipse.org/${PROJECT_NAME}.git .
git checkout ${BRANCH_NAME}
'''
}
}
}
}
stage('Build website (master) with Hugo') {
when {
branch 'master'
}
steps {
container('hugo') {
dir('hugo') {
sh 'hugo -b https://www.eclipse.org/${PROJECT_NAME}/'
}
}
}
}
stage('Build website (staging) with Hugo') {
when {
branch 'staging'
}
steps {
container('hugo') {
dir('hugo') {
sh 'hugo -b https://staging.eclipse.org/${PROJECT_NAME}/'
}
}
}
}
stage('Push to $env.BRANCH_NAME branch') {
when {
anyOf {
branch "master"
branch "staging"
}
}
steps {
sh 'rm -rf www/* && cp -Rvf hugo/public/* www/'
dir('www') {
sshagent(['git.eclipse.org-bot-ssh']) {
sh '''
git add -A
if ! git diff --cached --exit-code; then
echo "Changes have been detected, publishing to repo 'www.eclipse.org/${PROJECT_NAME}'"
git config user.email "${PROJECT_NAME}-[email protected]"
git config user.name "${PROJECT_BOT_NAME}"
git commit -m "Website build ${JOB_NAME}-${BUILD_NUMBER}"
git log --graph --abbrev-commit --date=relative -n 5
git push origin HEAD:${BRANCH_NAME}
else
echo "No changes have been detected since last build, nothing to publish"
fi
'''
}
}
}
}
}
}
Finally, you can create a multibranch pipeline job on your project's Jenkins instance. It will automatically be triggered on every new push to your Hugo source repository, build the website and push it to the git.eclipse.org/www.eclipse.org/&lt;project_name&gt;.git repository. As mentioned above, the Eclipse Foundation website's infrastructure will eventually pull the content of the latter and your website will be published and available on http://www.eclipse.org/<project_name>.
If you don't have a Jenkins instance already, ask for one. If you need assistance with the process, open a ticket.
By default, Jenkins project configurations using the GitLab Branch Source plugin are set up with 'Trusted Members' as the default option.
Definition of 'trusted members': [Recommended] Discover merge requests from forked projects whose authors have Developer/Maintainer/Owner access levels in the origin project.
To accept contributions from contributors with fork project, the project should:
- Configure the CI project by changing 'Discover merge requests from forks' to 'Members'.
- The project lead should add the user to the list of collaborators in PMI.
- The contributor should change the forked project's visibility to public.