The script will prompt you for your password twice, once at the beginning and once at the end. So, for example, the command to promote a weekly M build on the 3.0 maintenance branch would be as follows (ran from the /releng/control directory. The 3-part name associated with any CC projects, such as wtp-R3.0-M, wtp-R3.1-R, etc. ĭeletes the previous, older builds from the same project that is being promoted. ![]() That is, you can do this as long as there have been no more recent builds doneįor this project. Script once, to do the copy (only) and then run it again to do the send mail (only) once you've confirmed as the download replication can take from 10 to 60 minutes. Note: If sent at the same time the copy is done, the 'download' may not actually be available when peopleįirst read the mail. This is one way to 'sanity check' that the one that will be copied matches the one you think it is.Ī mail notification is sent to announcing the build has been "declared". If 'c' is not provided, no copy is done but the most recent one is listed to the console. Provides more output about what it's doingĪctually does copy the most recent version from the specified project. ![]() The options are all singe letters and technically optional (though not much is done if there are no options. Where build-project is one of the projects such as wtp-R3.0-M, wtp-R3.1-R, etc. The script can be ran with something like In those cases, you would have to "manually" delete any build directories that were more recent than the one you wanted to promote before using the scripts. 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. Note that "most recent" is something to be careful of. There is a script (a bash script) in the ntrol 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.Īs of this writing, the script can be ran from an SSH console on the machine, from the /shared/webtools/ntrol directory. For example, when we promote a Milestone build, then shortly after that we should remove the I-builds that led up to that milestone. this happens when we "change types" of builds. 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. To actually start showing up on mirrors takes several hours (and usually overnight). 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. 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. On the build machine, any builds during the week that are not promoted should be deleted. ![]() Besides these main things, there's also cleanup to do. 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). 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. There's basically two things that have to be done. 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. The second reason is that this makes it a little more apparent which build consumers and early testers can pick up. Since not many people download those, we would trigger a great deal of of unnecessary activity in the infrastructure if we put every build on download server. First, the build machine's files are not mirrored, which turns out to be much more efficient for day-to-day continuous build. Why doesn't the build script just put every build on the download server? There are a couple of reasons.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |