Jump to: navigation, search

Difference between revisions of "WTP/Build/How to promote a build"

< WTP‎ | Build
(New page: To "promote" a build, means to copy it from the build machine to the download machine. This happens, of course, after a build has been deemed promotable ... passed smoke tests or whatever ...)
 
(The Promote Automated Script)
Line 23: Line 23:
 
The options are all singe letters and technically optional (though not much is done if there are no options.  
 
The options are all singe letters and technically optional (though not much is done if there are no options.  
  
  v verbose: provides more output about what it's doing  
+
  v verbose:  
 +
  provides more output about what it's doing  
 
    
 
    
  c copy: actually does copy the most recent version from the specified project. If 'c' is not provided, no copy is done but the most recent one it detects is listed to console. This is one way to 'sanity check' that the one that will be copied matches up with the one you think it is.  
+
  c copy:  
 +
  actually does copy the most recent version from the specified project.  
 +
  If 'c' is not provided, no copy is done but the most recent one is listed to the console.  
 +
  This is one way to 'sanity check' that the one that will be copied matches the one you think it is.  
 
   
 
   
  d delete: deletes the previous, older builds from the same project that is being promoted.  
+
  d delete:  
 +
  deletes the previous, older builds from the same project that is being promoted.  
 
   
 
   
  p project: the 3-part name associated with any CC projects, such as wtp-R3.0-M, wtp-R3.1-R, etc.  
+
  p project:  
 +
  the 3-part name associated with any CC projects, such as wtp-R3.0-M, wtp-R3.1-R, etc.  
  
  

Revision as of 21:18, 12 September 2008

To "promote" a build, means to copy it from the build machine to the download machine. This happens, of course, after a build has been deemed promotable ... passed smoke tests or whatever other criteria there are for that build.

Background

Why doesn't the build script just put every build on the download server? There are a couple of reasons. First, the build machine's files are not mirrored, which turns out to be much more efficient for day-to-day continuous build. Since not many people download those, we would trigger a great deal of of unnecessary activity in the Eclipse.org infrastructure if we put every build on download server. The second reason is that this makes it a little more apparent which build consumers and early testers can pick up. We produce many builds throughout a given week, some of them have never even been downloaded or looked at by anyone so we don't want innocent users or testers downloading a very bad build.

Mechanics

There's basically two things that have to be done. One, copy the files. In our current setup, this is accomplished by copying a directory from the build machine somewhere in the /shared/webtools/committers directory to its download location, somewhere on ~/downloads/webtools/downloads/drops. The other thing that has to be done is that a few files have to have some URLs updated to reflect the new location (most URLs are relative, though, so are valid no matter what the top level directory is). Besides these main things, there's also cleanup to do. On the build machine, any builds during the week that are not promoted should be deleted. It is a good idea, though, to leave the build directory that is being in place, partially to give time for any downloads from users or testers to complete, if they happen to be getting the latest at the same time you promote. Plus, downloads from the build machine are faster or more available for many committers, since once copied to the download server, it can take 10 to 30 minutes (or more) to "show up" by the time it replicates. To actually start showing up on mirrors takes several hours (and usually overnight). There is another type of cleaning not really addressed here (that is, by the automation described below) and that is cleaning up old builds on the download server itself .... this happens when we "change types" of builds. For example, when we promote a Milestone build, then shortly after that we should remove the I-builds that led up to that milestone.

The Promote Automated Script

There is a script (a bash script) in the releng.control project called promote.sh that automates the tasks mentioned above: copies the most recent build in what ever project is named, fixes up the URLs, and removes all but the most recent build.

Note that "most recent" is something to be careful of. While it does not happen often, occasionally we'll do a "final" build, only to discover it didn't go well, and decide to promote some previous build instead. In those cases, you'd have to "manually" delete any build directories that were more recent than the one you wanted to promote, and then use the scripts.

The script can be ran with something like

./promote.sh  -[vcd]p build-project

where build-project is one of the projects such as wtp-R3.0-M, wtp-R3.1-R, etc.

The options are all singe letters and technically optional (though not much is done if there are no options.

v verbose: 
  provides more output about what it's doing 
 
c copy: 
  actually does copy the most recent version from the specified project. 
  If 'c' is not provided, no copy is done but the most recent one is listed to the console. 
  This is one way to 'sanity check' that the one that will be copied matches the one you think it is. 

d delete: 
  deletes the previous, older builds from the same project that is being promoted. 

p project: 
  the 3-part name associated with any CC projects, such as wtp-R3.0-M, wtp-R3.1-R, etc. 


So, for example, the command to promote a weekly M build on the 3.0 branch would be

./promote.sh -dcp wtp-R3.0-M