Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "Platform-releng/e4Build Build Id"

(Interesting points to keep in mind)
(obsoleting document on e4Build id)
 
(2 intermediate revisions by one other user not shown)
Line 1: Line 1:
 +
{{warning|This document, and the e4Build id, is obsolete. That "shared build id" is no longer used. In some sense, the id that is associated with Releng HIPP, namely genie.releng, has taken the place of "e4Build" id.}}
 +
 
== Purpose ==
 
== Purpose ==
  
Line 17: Line 19:
 
4. As a general rule, e4Build should only be used literally "for building" and if a "build user" needed to edit things, create directories, etc., in the /shared/eclipse area, they should work with their own committer ID. That directory (/shared/eclipse) has been set up so that the "group owner" should always be 'eclipse.platform.releng' so any committer that is a member of that linux group should be able to add, write, and delete any files or directories (no matter who created them) ... which is desirable, since it is, after all, a shared area for shared work. ({{bug|375104}}) [I have noticed exceptions to this, such as I think git purposely gives rw access only to "user" for the .git files of clones, where the user would normally be e4Build].  
 
4. As a general rule, e4Build should only be used literally "for building" and if a "build user" needed to edit things, create directories, etc., in the /shared/eclipse area, they should work with their own committer ID. That directory (/shared/eclipse) has been set up so that the "group owner" should always be 'eclipse.platform.releng' so any committer that is a member of that linux group should be able to add, write, and delete any files or directories (no matter who created them) ... which is desirable, since it is, after all, a shared area for shared work. ({{bug|375104}}) [I have noticed exceptions to this, such as I think git purposely gives rw access only to "user" for the .git files of clones, where the user would normally be e4Build].  
  
== Special modifications ==  
+
== Special, custom modifications ==  
  
 
Contrary to "Rule number 2" (above) a few modifications have been made for the convenience of e4Build users.  
 
Contrary to "Rule number 2" (above) a few modifications have been made for the convenience of e4Build users.  
Line 25: Line 27:
 
   cd ~/signingdir  
 
   cd ~/signingdir  
  
* Similar to the above, if you ever need to "watch" the signing log, an alias has been created to make it easier (again, hard to remember the exact location and name of signing que log).  
+
* Similar to the above, if you ever need to "watch" the signing log, an alias has been created to make it easier (again, hard to remember the exact location and name of signing que log). This note technically applies to when signed in as e4Build, but, there is only one log, so all "build masters" could create similar alias for their own committer ID. 
  
 
   tailsignerlog
 
   tailsignerlog
  
  
 +
== Adding your real email to crontab notifications ==
 +
 +
The e4Build id uses a number of "cronjobs" to do various things. If these fail, notification of that failure is by default sent to "e4Build@eclipse.org", which, as far as is known, goes no where (i.e. to no real person).
 +
 +
If you are a e4Build release engineer that would like to get crontab failure notices, or not, see the comments in the contab file.
 +
 +
In short, to get notices for everything by default, add your email to the MAILTO variable at the top of the file. For one possible example,
 +
 +
MAILTO=david_williams@us.ibm.com,pwebster@ca.ibm.com
 +
 +
To restrict your job to send notices only to yourself (or small group) of people, follow a pattern similar to what I do for the SDK builds:
 +
 +
# Swap out default list, and just notify david of eclipse sdk build problems
 +
ORIGMAILTO="$MAILTO"
 +
MAILTO=david_williams@us.ibm.com,daddavidw@gmail.com
 +
#Eclipse SDK builds
 +
# Nightly builds 8 PM every day
 +
0 22 * * *  /opt/public/eclipse/eclipse4N/mb4N.sh
 +
MAILTO="$ORIGMAILTO"
 +
  
  
  
[[Category:Eclipse_Platform_Releng| ]]
+
[[Category:Eclipse_Platform_Releng_Obsolete| ]]

Latest revision as of 10:20, 1 August 2016

Warning2.png
This document, and the e4Build id, is obsolete. That "shared build id" is no longer used. In some sense, the id that is associated with Releng HIPP, namely genie.releng, has taken the place of "e4Build" id.


Purpose

This page is to capture a few notes on e4Build build Id.

Central owner and contact

This id is "owned" by Paul Webster and at this time is "shared" by David Williams, John Arthorne, and Bogdan Gheorghe (and at times others) to do the various builds for the Eclipse Project; the Eclipse SDK, Orion, e4 Incubator, etc. Usually once a "build master" is given initial access to this shared id they set up access via SSH certificates so they don't require the password any longer (this allows Paul to change and safeguard the password at any time he'd like).

Interesting points to keep in mind

1. The ID has been given the right accesses and permissions to sign and commit/push tags to git, and it can push changes to the maps project. (See bug 374248)

2. As a general rule, nothing should be changed or stored in e4Build $HOME. Some things, such as .cvspass, .bashrc would in principle change how other "shared builds" run. So, please note any special cases or changes here on this page. The "storage constraint" is related to how Eclipse webmasters as set up the "build users" directory (or, mount). Its currently limited for all build users to be fairly small (currently mounted on /dev/sda7, there is only 300 Gigabytes allocated for all shared build users, including wtpBuild, orbitBuild, etc). In contrast, the /shared area is mounted on a file system with 2 terabytes, so that's the place to "store" things, if needed.

3. One implication of the above "rule" is that if people use Eclipse to do something during the build, they should be sure to point to a "workspace" in their own build area, or else the default will be used is ${user.home}/workspace. For example, you might use -data /shared/eclipse/e4/workspace-orion, or similar, when invoking your eclipse instance.

4. As a general rule, e4Build should only be used literally "for building" and if a "build user" needed to edit things, create directories, etc., in the /shared/eclipse area, they should work with their own committer ID. That directory (/shared/eclipse) has been set up so that the "group owner" should always be 'eclipse.platform.releng' so any committer that is a member of that linux group should be able to add, write, and delete any files or directories (no matter who created them) ... which is desirable, since it is, after all, a shared area for shared work. (bug 375104) [I have noticed exceptions to this, such as I think git purposely gives rw access only to "user" for the .git files of clones, where the user would normally be e4Build].

Special, custom modifications

Contrary to "Rule number 2" (above) a few modifications have been made for the convenience of e4Build users.

  • A symbolic link has been set up to the signing directory. Its hard to remember, so when logged in as e4Build, you can more easily get to it, to check your signing, or clean up old directories or files.
 cd ~/signingdir 
  • Similar to the above, if you ever need to "watch" the signing log, an alias has been created to make it easier (again, hard to remember the exact location and name of signing que log). This note technically applies to when signed in as e4Build, but, there is only one log, so all "build masters" could create similar alias for their own committer ID.
 tailsignerlog


Adding your real email to crontab notifications

The e4Build id uses a number of "cronjobs" to do various things. If these fail, notification of that failure is by default sent to "e4Build@eclipse.org", which, as far as is known, goes no where (i.e. to no real person).

If you are a e4Build release engineer that would like to get crontab failure notices, or not, see the comments in the contab file.

In short, to get notices for everything by default, add your email to the MAILTO variable at the top of the file. For one possible example,

MAILTO=david_williams@us.ibm.com,pwebster@ca.ibm.com

To restrict your job to send notices only to yourself (or small group) of people, follow a pattern similar to what I do for the SDK builds:

# Swap out default list, and just notify david of eclipse sdk build problems
ORIGMAILTO="$MAILTO"
MAILTO=david_williams@us.ibm.com,daddavidw@gmail.com
#Eclipse SDK builds
# Nightly builds 8 PM every day
0 22 * * *  /opt/public/eclipse/eclipse4N/mb4N.sh
MAILTO="$ORIGMAILTO"

Back to the top