Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 294919 - make the build's signing process more efficient
Summary: make the build's signing process more efficient
Status: RESOLVED WONTFIX
Alias: None
Product: Platform
Classification: Eclipse Project
Component: Releng (show other bugs)
Version: 3.6   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: 3.7   Edit
Assignee: Platform-Releng-Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on: 294921
Blocks:
  Show dependency tree
 
Reported: 2009-11-11 17:07 EST by Kim Moir CLA
Modified: 2010-06-03 17:55 EDT (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Kim Moir CLA 2009-11-11 17:07:08 EST
The signing process at eclipse takes our build about an hour.  For integration builds, this is rather inefficient because all of the bundles don't change every time.  Some background on how the build works:

When we run a build, we compare the bundles in the existing repo with the newly produced bundles.  If the bundle already exists in the repo, we use the old bundle in the zips.  The new bundles are discarded.  This replicates the user experience, where the user doesn't update their install unless there's a new version.  

From the perspective of the signing process, this is rather inefficient because we are signing bundles that we are discarding.  (In a nightly build, the qualifiers of the bundles are changed  to match the buildid so this doesn't apply.) The important case is for integration builds.  This case is especially useful during integration rebuilds where we only rebuild a few bundles.  

To fix this problem
1) Run the comparator before the bundles are signed
2) Generate a list of bundles that have changed
3) slice off these bundles from the repo
4) send them off to be signed
5) copy newly signed bundles into the repo
6) run p2.process.artifacts to update the artifact descriptors

For 1) the comparator needs to be updated have a parameter to ignore differences in the manifest (signed versus unsigned).  I talked to Andrew regarding this and he said it wouldn't be a problem so I'll open a bug against p2 for this issue.
Comment 1 Kim Moir CLA 2010-06-03 17:12:10 EDT
I'm going to close this bug. With the new hardware in place  at eclipse.org the signing process has become much much faster so it doesn't make sense to refactor our process.
Comment 2 David Carver CLA 2010-06-03 17:55:12 EDT
(In reply to comment #1)
> I'm going to close this bug. With the new hardware in place  at eclipse.org the
> signing process has become much much faster so it doesn't make sense to
> refactor our process.

Actually my take on it is that if there is anything that can be done to reduce the time regardless of CPU upgrades and speed, they should be done.  Again, lower priority, but refactoring processes is a good thing to do from time to time.