Jump to: navigation, search

Difference between revisions of "Hudson"

(Accessing the Internet using Proxy)
(Who are the Administrators)
 
(52 intermediate revisions by 16 users not shown)
Line 1: Line 1:
 +
= About Hudson =
 +
 +
Hudson is a continuous integration (CI) tool.  The [http://eclipse.org/hudson/ Hudson project] is hosted at Eclipse.org, and is in use on Eclipse servers for Eclipse projects as part of the [[CBI|Common Build Infrastrure (CBI)]].  This page is about the hosted service at Eclipse.org.  For more information on the project itself, or to download Hudson, please see the [http://eclipse.org/hudson/ Hudson project] page.
 +
 
= General Information  =
 
= General Information  =
  
The Eclipse Foundation runs a Hudson continuous integration server that eclipse hosted projects can take advantage of for their builds.  Currently this is hosted here: https://build.eclipse.org/hudson, but due to stability issues a new 'stable' instance has been created and is hosted here: https://hudson.eclipse.org/hudson .  The Hudson server allows for the execution of Continuous Integration Builds, Nightly Builds, Integration Builds, Release Builds, and Testing. The 'stable' Hudson instance is maintained by the Eclipse Webmasters. The planned Hudson sandbox instance will be maintained by the eclipse community. Job creation will be limited to committers and admin rights are administered by the community as a whole.
+
Hudson instances are maintained by the Eclipse Webmasters. The Hudson CI servers are available in two different offerings (each explained below):
  
 +
* Hudson Shared instance: https://hudson.eclipse.org/shared/
 +
* Hudson Instance Per Project (HIPP): https://hudson.eclipse.org/
  
== Migrating to the 'new' Eclipse.org Hudson service ==
+
== Asking for Help ==
  
If you have a build that is currently running on the 'unstable' Hudson instance(hosted on https://build.eclipse.org/hudson) and you wish to move to the Hudson instance managed by the Foundation(hosted on https://hudson.eclipse.org/hudson) you will need to file a bug against community->hudson with a subject like  'Move job job-name to hudson.eclipse.org'.  Webmaster will then import the job and close the bug.  Please note that the stable instance does not provide the same plugins as the unstable instance.  You may also need to update your job configuration to account for differences in the Hudson deployment.
+
* Need help setting up your instance: contact webmaster @ eclipse.org or your project mentors
 +
* 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
  
== Hudson configuration and tools ==
+
= HIPP =
  
Presently the 'new' hudson setup uses 3 SLES 11 x86_64 machines (1 master and 2 slaves), with bash as the default shellThese machines are behind a firewall so any outbound http(s) connections are proxied.
+
HIPP (Hudson Instance Per Project) instances are recommended for those projects who prefer flexibility and convenience with their CI system, perhaps at the expense of security and webmaster supportA single Linux master is provided, and the instance is run under the security context of your project. Optionally, a project's Hudson instance can be configured to write into a project's downloads area and can be given write access to the code repository for automatic tagging of builds. This does create a security risk - see https://bugs.eclipse.org/bugs/show_bug.cgi?id=375350#c42 for a fix.  Webmasters will install most plugins you request, including the Gerrit plugin, but will offer little support.  In time, projects will be offered self-serve restarts and re-imaging of their instances.
  
The following global variables are set(identically across installs):
+
== Requesting a HIPP instance ==
  
*JVM_OPTS: proxy data (see "Accessing the Internet" below)
+
Please file [https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Community&component=Hudson a bug] against Eclipse Foundation > Community > Hudson to request your project's own instance. Please ensure your project lead can +1 the request. Please specify if you would like to use the Gerrit Trigger plugin, and if you wish to grant write access to your download or code repositories.
*ANT_ARGS: proxy data
+
*ANT_OPTS: proxy data
+
  
Each node also has a .m2/settings.xml file with the proxy data.
+
{{Note|About write access| If your git repo is handled by gerrit, granting write access to your code repositories is a different procedure, so you must ask specifically for it. If you don't use Gerrit, then granting write access to your download area automatically grants write access to your code repositories and vice-versa.}}
  
==Tools(and locations)==
+
{{important|Security issues| There may be security issues related to using the Gerrit plugin and there may be security issues related to allowing the CI system to write directly to your code repos and downloads area. If you request plugins other than those available on the Shared instance, webmaster may not be able to help troubleshoot any issues that you may encounter with your instance.}}
  
*Maven 2.2.1 (installed automatically)
+
{{important|No more HIPPs| Since the Hudson project became dormant, as of 2017 no more HIPPs will be provisioned. Instead JIPPs (Jenkins Instance Per Project) will be provisioned..}}
*Maven 3.0 alpha 5 (installed automatically)
+
*Maven 3.0-alpha-5-local (/shared/common/apache-maven-3.0-alpha-5)
+
*Maven 3.0-alpha-6-local (/shared/common/apache-maven-3.0-alpha-6)
+
*Maven 3.0-Beta-1 (/shared/common/apache-maven-3.0-beta-1)
+
  
*Sun Java 5 SR 22 64bit (/shared/common/jdk-1.5.0-22.x86_64)
+
== HIPP slaves ==
*Sun Java 5 R 16 32bit (/shared/common/jdk-1.5.0_16)
+
*Sun Java 5 R 22 64bit (/shared/common/jdk-1.5.0-22.x86_64)
+
*Sun Java 6 R 21 32bit (/shared/common/sun-jdk1.6.0_21_i586)
+
*Sun Java 6 R 21 64bit (/shared/common/sun-jdk1.6.0_21_x64)
+
  
*Apache-ant-1.7.1 (/shared/common/apache-ant-1.7.1)
+
Both Shared and HIPP Hudson setups use SLES 11 x86_64 machines for Linux slaves. Windows 7 and Mac OS X slaves are available for UI testing on the Shared instance. These servers are behind a firewall so any outbound http(s) connections are proxied.  
*Apache-ant-1.7.0 (/shared/common/apache-ant-1.7.0)
+
*Apache-ant-1.6.5 (/shared/common/apache-ant-1.6.5)
+
  
*Headless Buckminster 3.6 (/shared/common/buckminster-3.6)
+
Platforms available as HIPP slaves:
*Buckminster 3.6 Integration (installed automatically)
+
* Fedora 20 x86_64
 +
* CentOS 7 x86_64
 +
* OpenSuSE 13.1 x86_64
  
== Accessing the Internet using Proxy ==
+
HIPP slaves are only provisioned for those projects who have a need. To request a HIPP slave, please [https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Community&component=Hudson&short_desc=HIPP%20slave%20needed%20for%20my%20project file a bug].
  
Each Hudson instance has unrestricted access to the Internet by using proxy.eclipse.org.  The shell environment variables below are set for the hudson build user.  If your build process overrides, or bypasses these variables, you must instruct your tools to use the proxy service to access external sites.
+
You can also [[Hudson/Connecting HIPP to an external slave | connect to your own external slave]].
  
    ftp_proxy=http://proxy.eclipse.org:9898
+
=== Choosing the right slave ===
    http_proxy=http://proxy.eclipse.org:9898
+
    https_proxy=http://proxy.eclipse.org:9898
+
    no_proxy='localhost, 127.0.0.1, 172.30.206.0, eclipse.org'
+
  
    JAVA_ARGS="-Dhttp.proxyHost=proxy.eclipse.org -Dhttp.proxyPort=9898 -Dhttps.proxyHost=proxy.eclipse.org -Dhttps.proxyPort=9898 -Dhttp.nonProxyHosts=*.eclipse.org -Dhttps.nonProxyHosts=*.eclipse.org -Dftp.proxyHost=proxy.eclipse.org -Dftp.proxyPort=9898 -Dftp.nonProxyHosts=*.eclipse.org"
+
* '''hudson-slave1, hudson-slave2, hudson-slave4''' - these are the main build nodes for Hudson jobs. You can specify them by name or by using the 'build2' label.  
 +
* '''fastlane''' - this slave is intended for usage during a release train crunch when re-spins may require more capacity than hudson-slave1&2 can provide. By default jobs should not run here.  
 +
* '''mac-tests and windows7tests''' - these 2 slaves are meant for running UI tests for their respective OS versions. By default jobs should not run on either slave.
  
    JVM_OPTS="-Dhttp.proxyHost=proxy.eclipse.org -Dhttp.proxyPort=9898 -Dhttps.proxyHost=proxy.eclipse.org -Dhttps.proxyPort=9898 -DhttpnonProxyHosts=*.eclipse.org -DhttpsnonProxyHosts=*.eclipse.org -Dftp.proxyHost=proxy.eclipse.org -Dftp.proxyPort=9898 -DftpnonProxyHosts=*.eclipse.org"
+
See also: [[Hudson server performance metrics]]
  
    ANT_ARGS="-Dhttp.proxyHost=proxy.eclipse.org -Dhttp.proxyPort=9898 -Dhttps.proxyHost=proxy.eclipse.org -Dhttps.proxyPort=9898 -DhttpnonProxyHosts=*.eclipse.org -DhttpsnonProxyHosts=*.eclipse.org -Dftp.proxyHost=proxy.eclipse.org -Dftp.proxyPort=9898 -DftpnonProxyHosts=*.eclipse.org"
+
= Shared Instance =
  
    ANT_OPTS="-Dhttp.proxyHost=proxy.eclipse.org -Dhttp.proxyPort=9898 -Dhttps.proxyHost=proxy.eclipse.org -Dhttps.proxyPort=9898 -DhttpnonProxyHosts=*.eclipse.org -DhttpsnonProxyHosts=*.eclipse.org -Dftp.proxyHost=proxy.eclipse.org -Dftp.proxyPort=9898 -DftpnonProxyHosts=*.eclipse.org"
+
The Shared instance is recommended for general purpose builds and tests, and for all UI tests. Shared Hudson has several build slaves, a limited yet stable tool set, and full webmaster support. Shared Hudson cannot write into your downloads area or tag releases in your Git repo. Furthermore, the Gerrit trigger plugin is not permitted to run here.
  
=== Additional Troubleshooting ===
+
= Server Storage =
  
From Martin Taal, via [http://www.eclipse.org/forums/index.php?t=tree&goto=628738#page_top Forums]:
+
[[Image:Build infra layout.png|thumb|Build and Hudson storage layout]] Three tiers of storage are available for storing Workspaces, build artifacts, nightly and release builds. For optimal build performance and service availability, it is important that you use each storage device according to its intended purpose.  
  
Buckminster cvs materializing, uses a proxy, how is this configured?
+
The image on the right illustrates the three storage tiers and their intended purpose.
  
To finish this thread. Michael Wenz pointed me to a change made in the cdo build (to solve this issue), a snippet from
+
If you are using a HIPP instance for your builds, the medium and long-term storage is accessible via the local filesystem to copy build artifacts to. The locations are as follows:
his email to me:
+
  
But I saw that the CDO build is green again and they still do an Ant call from Hudson that again triggers Buckminster.
+
    # Medium-term storage:
Previously that build failed with the same exception as ours did or do.
+
    /shared/<project id with . replaced by />
 +
    # Long-term storage:
 +
    /home/data/httpd/download.eclipse.org/<project name />
  
Not sure what these guys changed, but I saw that they added something in their build.xml that seems to fix this. I found
+
For example, the ELK project's ID is modeling.elk and can thus publish its build artifacts to the following locations:
2 snippets that appear to be in connection with this:
+
...
+
<condition property="no.proxy" value="${env.no_proxy}, dev.eclipse.org" else="dev.eclipse.org">
+
<isset property="env.no_proxy" />
+
</condition>
+
...
+
  
...
+
    /shared/modeling/elk/
<!-- Launch the eclipse application -->
+
    /home/data/httpd/download.eclipse.org/elk/
<java fork="true" jar="${@{app}.launcher}" dir="${@{app}.deploy.dir}" failonerror="true">
+
<env key="no_proxy" value="${no.proxy}" />
+
<properties />
+
<!-- Uncomment to debug <jvmarg value=" -agentlib:jdwp=transport=dt_socket,address=8000,server=y,sus pend=y "/> -->
+
<args />
+
</java>
+
...
+
  
== Hudson for Committers  ==
+
Be sure to request your HIPP instance to actually have write access to these locations. If there is a problem, file a bug against [https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Community Eclipse Foundation > Community > Servers].
 +
 
 +
See [[Milestone and Release Builds]].
 +
 
 +
 
 +
= Hudson configuration =
 +
 
 +
== Tools (and locations) ==
 +
 
 +
* apache-maven-latest (/shared/common/apache-maven-latest)
 +
* apache-maven-3.0.5 (/shared/common/apache-maven-3.0.5)
 +
 
 +
* jdk1.8.0-latest (/shared/common/jdk1.8.0_x64-latest)
 +
* jdk1.7.0-latest (/shared/common/jdk1.7.0-latest)
 +
* jdk1.6.0-latest (/shared/common/jdk1.6.0-latest)
 +
* jdk1.5.0-latest (/shared/common/jdk1.5.0-latest)
 +
 
 +
* apache-ant-1.9.6 (/shared/common/apache-ant-1.9.6)
 +
 
 +
* gradle-latest (/shared/common/gradle-latest)
 +
* gradle-3.1 (/shared/common/gradle-3.1)
 +
 
 +
== Accessing the Internet using Proxy  ==
 +
 
 +
Since April 2017 the proxy is no longer required to access the internet from HIPP instances.
 +
 
 +
= Additional Troubleshooting Tips  =
 +
 
 +
== Buckminster CVS materializing: proxy error: Forbidden  ==
 +
 
 +
From Martin Taal, via [http://www.eclipse.org/forums/index.php?t=tree&goto=628738#page_top Forums]:
 +
 
 +
Buckminster cvs materializing, uses a proxy, how is this configured?
 +
 
 +
To finish this thread. Michael Wenz pointed me to a change made in the cdo build (to solve this issue), a snippet from his email to me:
 +
 
 +
But I saw that the CDO build is green again and they still do an Ant call from Hudson that again triggers Buckminster. Previously that build failed with the same exception as ours did or do.
 +
 
 +
Not sure what these guys changed, but I saw that they added something in their build.xml that seems to fix this. I found 2 snippets that appear to be in connection with this: ... &lt;condition property="no.proxy" value="${env.no_proxy}, dev.eclipse.org" else="dev.eclipse.org"&gt; &lt;isset property="env.no_proxy" /&gt; &lt;/condition&gt; ...
 +
 
 +
... <!-- Launch the eclipse application --> &lt;java fork="true" jar="${@{app}.launcher}" dir="${@{app}.deploy.dir}" failonerror="true"&gt; &lt;env key="no_proxy" value="${no.proxy}" /&gt; &lt;properties /&gt; <!-- Uncomment to debug <jvmarg value=" -agentlib:jdwp=transport=dt_socket,address=8000,server=y,sus pend=y "/> --> &lt;args /&gt; &lt;/java&gt; ...
 +
 
 +
= Hudson for Committers  =
  
 
*[[Common Build Infrastructure/Getting Started/Build In Hudson|Build in Hudson]] - Information on requesting jobs, running jobs, setting up builds.  
 
*[[Common Build Infrastructure/Getting Started/Build In Hudson|Build in Hudson]] - Information on requesting jobs, running jobs, setting up builds.  
*[[Building an RCP application with hudson (Buckminster)|RCP apps with Buckminster on Hudson]]
+
*[[Building an RCP application with hudson (Buckminster)|RCP apps with Buckminster on Hudson]]  
*[[Teneo/Teneo_Build_Setup|Building an Eclipse project (Teneo) with Buckminster and Hudson]]
+
*[[Teneo/Teneo Build Setup|Building an Eclipse project (Teneo) with Buckminster and Hudson]]  
 
*[[Common Build Infrastructure/Getting Started#In_Hudson|Athena Common Builder on Hudson]]  
 
*[[Common Build Infrastructure/Getting Started#In_Hudson|Athena Common Builder on Hudson]]  
*[[Hudson/Maven|Maven on Hudson]]
 
 
*[[Hudson/HowTo|How to....]]
 
*[[Hudson/HowTo|How to....]]
  
== Hudson for Administrators ==
+
== Hudson for Committer Project-level Administration ==
 +
 
 +
Normally "project level" administration is defined for a Hudson job. This allows for only one or a few committers to have "full access" to the job, to do builds, change the configuration, or even delete the job. To give access to everyone, say to "read" the builds, you can add the user "anonymous" and mark the "read" check box. Typically, it is desired to have some "in between" access to all the committers of a project, for example, to maybe any committer can kick off a build, but only the project-level administrator can change the configuration. If this is desired, there is a "role" groups that can be used instead of listing all committers by name. The "role" name is formed by perpending "ROLE_" to the upper case version of the Linux group that defines the committers. For example, EPP committers are authorized using the Linux group ''technology.packaging'', so their Hudson group would be ROLE_TECHNOLOGY.PACKAGING. So, as an example, the project level authorization might look like the following, from the Hudson "configure project" page: <br>
 +
 
 +
[[Image:Projectlevel.png|Example Project Level Security settings]]
 +
 
 +
If using the Promoted Builds plugin with a Promotion Criterion of "Only when manually approved", you can also use "role" groups (using the aforementioned "ROLE_" syntax). In fact, you *should* at least restrict the approvers to the group of project committers, as otherwise any anonymous can run a promotion job ([https://bugs.eclipse.org/bugs/show_bug.cgi?id=424619 Bug 424619]).
 +
 
 +
= Hudson for Administrators  =
  
 
*[[Common Build Infrastructure/Managing Hudson|Manage Hudson]]  
 
*[[Common Build Infrastructure/Managing Hudson|Manage Hudson]]  
 
*[[Hudson/Admin/UpgradeHudson|Upgrade Hudson]]  
 
*[[Hudson/Admin/UpgradeHudson|Upgrade Hudson]]  
*[[Hudson/Admin/Installed_Plugins|Installed Plugins]]
+
*[[Hudson/Admin/Installed Plugins|Installed Plugins]]
  
=== Duties of Administrators ===
+
== Duties of Administrators ==
  
 
#Hudson upgrades and restarts  
 
#Hudson upgrades and restarts  
Line 112: Line 146:
 
#Monitor the Hudson Inbox.
 
#Monitor the Hudson Inbox.
  
=== Who are the Adminstrators ===
+
== Who are the Administrators  ==
  
*Nick Boldt
+
* Eclipse Webmasters - webmaster@eclipse.org
*Kim Moir
+
* Mikaël Barbero
*David Carver
+
*Thomas Hallgren
+
*Chris Aniszczyk
+
  
Please add other known administrators.
+
You can contact the Hudson admins by opening [https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Community&component=Hudson a bug]
  
== Hudson for Distributed Builds  ==
+
= Hudson for Distributed Builds  =
  
 
*Testing on Multiple Platforms  
 
*Testing on Multiple Platforms  
Line 128: Line 159:
 
*How do I use the Test Slave Node to run Tests?
 
*How do I use the Test Slave Node to run Tests?
  
[[Category:Releng]]
+
[[Category:Releng]] [[Category:Hudson]]
[[Category:Hudson]]
+

Latest revision as of 08:12, 31 August 2017

About Hudson

Hudson is a continuous integration (CI) tool. The Hudson project is hosted at Eclipse.org, and is in use on Eclipse servers for Eclipse projects as part of the Common Build Infrastrure (CBI). This page is about the hosted service at Eclipse.org. For more information on the project itself, or to download Hudson, please see the Hudson project page.

General Information

Hudson instances are maintained by the Eclipse Webmasters. The Hudson CI servers are available in two different offerings (each explained below):

Asking for Help

  • Need help setting up your instance: contact webmaster @ eclipse.org or your project mentors
  • 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

HIPP

HIPP (Hudson Instance Per Project) instances are recommended for those projects who prefer flexibility and convenience with their CI system, perhaps at the expense of security and webmaster support. A single Linux master is provided, and the instance is run under the security context of your project. Optionally, a project's Hudson instance can be configured to write into a project's downloads area and can be given write access to the code repository for automatic tagging of builds. This does create a security risk - see https://bugs.eclipse.org/bugs/show_bug.cgi?id=375350#c42 for a fix. Webmasters will install most plugins you request, including the Gerrit plugin, but will offer little support. In time, projects will be offered self-serve restarts and re-imaging of their instances.

Requesting a HIPP instance

Please file a bug against Eclipse Foundation > Community > Hudson to request your project's own instance. Please ensure your project lead can +1 the request. Please specify if you would like to use the Gerrit Trigger plugin, and if you wish to grant write access to your download or code repositories.

Note.png
About write access
If your git repo is handled by gerrit, granting write access to your code repositories is a different procedure, so you must ask specifically for it. If you don't use Gerrit, then granting write access to your download area automatically grants write access to your code repositories and vice-versa.


Important.png
Security issues
There may be security issues related to using the Gerrit plugin and there may be security issues related to allowing the CI system to write directly to your code repos and downloads area. If you request plugins other than those available on the Shared instance, webmaster may not be able to help troubleshoot any issues that you may encounter with your instance.


Important.png
No more HIPPs
Since the Hudson project became dormant, as of 2017 no more HIPPs will be provisioned. Instead JIPPs (Jenkins Instance Per Project) will be provisioned..


HIPP slaves

Both Shared and HIPP Hudson setups use SLES 11 x86_64 machines for Linux slaves. Windows 7 and Mac OS X slaves are available for UI testing on the Shared instance. These servers are behind a firewall so any outbound http(s) connections are proxied.

Platforms available as HIPP slaves:

  • Fedora 20 x86_64
  • CentOS 7 x86_64
  • OpenSuSE 13.1 x86_64

HIPP slaves are only provisioned for those projects who have a need. To request a HIPP slave, please file a bug.

You can also connect to your own external slave.

Choosing the right slave

  • hudson-slave1, hudson-slave2, hudson-slave4 - these are the main build nodes for Hudson jobs. You can specify them by name or by using the 'build2' label.
  • fastlane - this slave is intended for usage during a release train crunch when re-spins may require more capacity than hudson-slave1&2 can provide. By default jobs should not run here.
  • mac-tests and windows7tests - these 2 slaves are meant for running UI tests for their respective OS versions. By default jobs should not run on either slave.

See also: Hudson server performance metrics

Shared Instance

The Shared instance is recommended for general purpose builds and tests, and for all UI tests. Shared Hudson has several build slaves, a limited yet stable tool set, and full webmaster support. Shared Hudson cannot write into your downloads area or tag releases in your Git repo. Furthermore, the Gerrit trigger plugin is not permitted to run here.

Server Storage

Build and Hudson storage layout
Three tiers of storage are available for storing Workspaces, build artifacts, nightly and release builds. For optimal build performance and service availability, it is important that you use each storage device according to its intended purpose.

The image on the right illustrates the three storage tiers and their intended purpose.

If you are using a HIPP instance for your builds, the medium and long-term storage is accessible via the local filesystem to copy build artifacts to. The locations are as follows:

   # Medium-term storage:
   /shared/<project id with . replaced by />
   # Long-term storage:
   /home/data/httpd/download.eclipse.org/<project name />

For example, the ELK project's ID is modeling.elk and can thus publish its build artifacts to the following locations:

   /shared/modeling/elk/
   /home/data/httpd/download.eclipse.org/elk/

Be sure to request your HIPP instance to actually have write access to these locations. If there is a problem, file a bug against Eclipse Foundation > Community > Servers.

See Milestone and Release Builds.


Hudson configuration

Tools (and locations)

  • apache-maven-latest (/shared/common/apache-maven-latest)
  • apache-maven-3.0.5 (/shared/common/apache-maven-3.0.5)
  • jdk1.8.0-latest (/shared/common/jdk1.8.0_x64-latest)
  • jdk1.7.0-latest (/shared/common/jdk1.7.0-latest)
  • jdk1.6.0-latest (/shared/common/jdk1.6.0-latest)
  • jdk1.5.0-latest (/shared/common/jdk1.5.0-latest)
  • apache-ant-1.9.6 (/shared/common/apache-ant-1.9.6)
  • gradle-latest (/shared/common/gradle-latest)
  • gradle-3.1 (/shared/common/gradle-3.1)

Accessing the Internet using Proxy

Since April 2017 the proxy is no longer required to access the internet from HIPP instances.

Additional Troubleshooting Tips

Buckminster CVS materializing: proxy error: Forbidden

From Martin Taal, via Forums:

Buckminster cvs materializing, uses a proxy, how is this configured?

To finish this thread. Michael Wenz pointed me to a change made in the cdo build (to solve this issue), a snippet from his email to me:

But I saw that the CDO build is green again and they still do an Ant call from Hudson that again triggers Buckminster. Previously that build failed with the same exception as ours did or do.

Not sure what these guys changed, but I saw that they added something in their build.xml that seems to fix this. I found 2 snippets that appear to be in connection with this: ... <condition property="no.proxy" value="${env.no_proxy}, dev.eclipse.org" else="dev.eclipse.org"> <isset property="env.no_proxy" /> </condition> ...

... <java fork="true" jar="${@{app}.launcher}" dir="${@{app}.deploy.dir}" failonerror="true"> <env key="no_proxy" value="${no.proxy}" /> <properties /> <args /> </java> ...

Hudson for Committers

Hudson for Committer Project-level Administration

Normally "project level" administration is defined for a Hudson job. This allows for only one or a few committers to have "full access" to the job, to do builds, change the configuration, or even delete the job. To give access to everyone, say to "read" the builds, you can add the user "anonymous" and mark the "read" check box. Typically, it is desired to have some "in between" access to all the committers of a project, for example, to maybe any committer can kick off a build, but only the project-level administrator can change the configuration. If this is desired, there is a "role" groups that can be used instead of listing all committers by name. The "role" name is formed by perpending "ROLE_" to the upper case version of the Linux group that defines the committers. For example, EPP committers are authorized using the Linux group technology.packaging, so their Hudson group would be ROLE_TECHNOLOGY.PACKAGING. So, as an example, the project level authorization might look like the following, from the Hudson "configure project" page:

Example Project Level Security settings

If using the Promoted Builds plugin with a Promotion Criterion of "Only when manually approved", you can also use "role" groups (using the aforementioned "ROLE_" syntax). In fact, you *should* at least restrict the approvers to the group of project committers, as otherwise any anonymous can run a promotion job (Bug 424619).

Hudson for Administrators

Duties of Administrators

  1. Hudson upgrades and restarts
  2. New Hudson accounts
  3. Add plugins
  4. Set policy for Hudson usage
  5. Watch changes to this wiki page
  6. Monitor the Hudson Inbox.

Who are the Administrators

  • Eclipse Webmasters - webmaster@eclipse.org
  • Mikaël Barbero

You can contact the Hudson admins by opening a bug

Hudson for Distributed Builds

  • Testing on Multiple Platforms
  • What is the Test-Slave Node?
  • How do I use the Test Slave Node to run Tests?