If you are removing an '''accidentally''' promoted build, you will also need to:

If you are removing an '''accidentally''' promoted build, you will also need to:

Line 206:

Line 224:

5. Delete the entry from the releases table of the Search CVS database so it will vanish from the Release Notes. Use [http://build.eclipse.org/modeling/mdt/build/removeRelease.php this webpage]. If you don't see your build listed, then it hasn't been loaded yet, and you can safely skip this step.

5. Delete the entry from the releases table of the Search CVS database so it will vanish from the Release Notes. Use [http://build.eclipse.org/modeling/mdt/build/removeRelease.php this webpage]. If you don't see your build listed, then it hasn't been loaded yet, and you can safely skip this step.

build_timestamp is "build_" plus the timestamp of the build for which you want to remove its tag from CVS. For example, for a milestone build 1.0.0M6a (S200604131352) (RC1, use build_200604131352.

Note that in order to remove tags from within org.eclipse.emft/releng you must be a member of the emft-releng group on dev.eclipse.org, or have similar write access via ACL.

Cleaning Failed Builds

Failed builds can occupy up to 2G of space each, which can chew up the disk pretty fast. To purge the temporary files left over from a failed build, you can either delete them by hand, or run the /home/www-data/build/modeling/scripts/cleanBuildFolder.sh script at a folder. For ease of use, you can symlink it in your build folder:

web_user is the id on your build server which runs the Apache webserver processes, eg., apache or www-data

Removing Old Builds

The simplest way to remove old builds is simply to delete them, both from the build server and from the public download1.eclipse.org server. Doing so will also (eventually) cause them to be removed from the eclipse.org mirrors.

Manual Delete From Build Server

To delete an old build, ssh to your build server, then run, for example:

If you are removing an accidentally promoted build, you will also need to:

update your RSS feed to remove that <entry>

ask User:Nickb to update the Search CVS database to remove the build from the releases table, eg.:

delete from releases where project='org.eclipse.emf' and component='org.eclipse.net4j' \
and vanityname='M200809091234' limit 1;

You may want to rollback the update site, too. Run this script to back up the latest addition to the update site:

/home/www-data/build/modeling/scripts/buildUpdateSiteRollback.sh

Archiving Builds on Production Server (download.eclipse.org)

Nightly builds can just be destroyed, but consumers of your component may have longer-term dependencies
on Integration builds. After a couple of releases, maybe even milestone builds want to be cleared away.
This can all be accomplished safely by archiving a build. A build that is in the archive doesn't
take up space on the main Eclipse download server or its mirrors, but is still accessible in the event
that it is needed via the download.php?file=/path/to/zipfile.zip URL.

Simply move your build from from the main download area to the archive area:

For old releases (once 0.8.2 is out, you might want to archive 0.8.0 and 0.8.1), you can copy the build over to archive.eclipe.org as above, then update your downloads page's extras-*.php file to explicitly list these builds in the $oldrels array. See examples below.

Remove Entries From site*.xml

In addition to deleting jars, you must also remove the entries from site-interim.xml. This file must be edited in CVS then checked out to the local filesystem to cause the removed builds to disappear.

If you do not update the file in CVS, but only edit it locally, the next UM jar build will recreate the removed entries since it extracts the latest version of that file from CVS before adding to it. To update the file in CVS and push it to eclipse.org, ssh to your build server or to any machine that can ssh to dev.eclipse.org, then:

Build.php Dependency URL Cleanup

Note that the most recent entries are listed at the bottom of the file, so delete from the top down (starting on line 3). If you delete too many, you can always re-add them using the web UI of build.php.

Removing or Replacing a Bad Build

Yes, it happens. You need to trash a milestone build and replace it with an M5a version. We've been there. Here's the steps you need to follow to make a bad build vanish forever using a hypothetical example.

0. Start a new build. This takes the most time and all the remaining steps can be done in parallel.

3. Check out your project's RSS feed from CVS, remove the bad entry, and commit your changes. When you promote the replacement build, this file will be promoted to the correct place on download1.eclipse.org. The RSS feed controls what releases are loaded in the Search CVS / Release Notes database, so you must remove the bad entry.

5. Delete the entry from the releases table of the Search CVS database so it will vanish from the Release Notes. Use this webpage. If you don't see your build listed, then it hasn't been loaded yet, and you can safely skip this step.