Diff for "Translations/GenerateTemplatesOnLocalBuildFarm"

Not logged in - Log In / Register

Differences between revisions 1 and 40 (spanning 39 versions)
Revision 1 as of 2010-03-08 13:04:20
Size: 4075
Editor: jtv
Comment:
Revision 40 as of 2010-03-24 01:11:48
Size: 6635
Editor: jtv
Comment:
Deletions are marked like this. Additions are marked like this.
Line 6: Line 6:

== Patches ==

 * For debugging, edit {{{lib/lp/buildmaster/manager.py}}} and replace {{{logging.INFO}}} with {{{logging.DEBUG}}}.
 * Hitting [[Bug:545604]]. In `TranslationTemplatesBuildBehavior.updateBuild_WAITING`, try replacing this line:
{{{
build_status = self.extractBuildStatus(slave_status)
}}}
with
{{{
build_status = "OK"
}}}
Line 16: Line 28:
There's a bug somewhere in Windmill that may break access to local branches through http. There's a bug somewhere in Windmill that may break access to local branches through http.  [[https://bugs.launchpad.net/bugs/534399|This bug is scheduled to be fixed soon]].
Line 41: Line 53:
== Getting branch updates noticed == == Setting up the testing environment in a branch ==
Line 44: Line 56:
 * Substituting your email address, run (parts may fail, but it's probably okay):  * Substituting your email address, but ''not'' one that is also in the sample data, run (parts may fail, but it's probably okay):
Line 46: Line 58:
make schema
make run_codehosting >/dev/null 2>&1 &
# Wait until that's all up and running...
Line 48: Line 63:
make run_codehosting >/dev/null 2>&1 &
Line 50: Line 64:
 * Open launchpad.dev in browser, log in as <your@email.address>, with password "test"

== Preparing the slave ==

Follow the instructions for setting up a local buildd slave at [[BuildFarm/TryOutBuildSlave]].
Skip the part where it tells you to run Launchpad, since you're already running it. You should end up with a shell open in a chroot for your simulated build slave. Keep it running; we're going to use that slave!

Did you obtain the Lucid chroot tarball as described on that page? Good. Give it to your running Launchpad instance and tell it to use it for Lucid:
{{{
  scripts/ftpmaster-tools/manage-chroot.py -s lucid -a i386 add -f chroot-ubuntu-lucid.tar.bz2
}}}


== Making some branch updates to generate templates from ==

 * Open https://launchpad.dev/ in browser, log in as <your@email.address>, with password "test"
Line 79: Line 108:
psql launchpad_dev -c 'select * from branchjob join job on job.id=branchjob.job join buildqueue on buildqueue.job=job.id where branchjob.job_type=6' psql launchpad_dev -c '
    
select *
   
from branchjob
   
join job on job.id=branchjob.job
   
join buildqueue on buildqueue.job=job.id
   
where branchjob.job_type=6
    order by job.id
'
Line 82: Line 117:
It will show a {{{branch_url}}} parameter to be passed to the slave, pointing to your branch: http://bazaar.launchpad.dev/~ppa-user/bf-test/bf-test
Line 83: Line 119:
== Preparing the slave ==

Follow the instructions for setting up a local buildd slave at [[BuildFarm/TryOutBuildSlave]].
Skip the part where it tells you to run Launchpad, since you're already running it.

Unfortunately the branch_url parameter you see in the json_data will not work on a dev system. So we have to hack it up a bit:
/!\ Some system setups apparently can't access this branch. Try this:
Line 90: Line 121:
psql launchpad_dev -c "update branchjob set json_data = '{\"branch_url\": \"http://code.launchpad.dev/bf-test\"}' where branchjob.job_type=6 and json_data like '%http://bazaar.launchpad.dev/~ppa-user/bf-test/bf-test%'" pushd /tmp
bzr export export-experiment http://bazaar.launchpad.dev/~ppa-user/bf-test/bf-test
Line 93: Line 125:
XXX: Actually that won't work either because the slave doesn't know about code.launchpad.dev. Have to get bazaar.launchpad.dev working. If that succeeds and creates a copy of bf-test in a directory called export-experiment, then it's fine; otherwise, re-do your rocketfuel setup by running {{{rocketfuel-setup}}}. And remove your branch. And start over. Sorry!
Line 95: Line 127:
TODO: Run cronscripts/buildd-queue-builder.py
== Simulating a builder ==

Now we tell Soyuz that your local buildd slave is in fact Bob the Builder.

Logged in as an admin (I suggest using a different browser so as not to break your ongoing session), check the Virtualized checkbox at https://launchpad.dev/builders/bob/+edit and enter an arbitrary hostname under Virtual Machine Host. Clear the "Builder State OK" checkbox to convince it not to continue building firefox for hoary, as it's been trying to do for the past few years.

Submit. Wait for a few seconds. Go back to the form and re-check "Builder State OK." Submit.


== Running the job on the slave ==

After a while, the buildd master should dispatch your job to Bob the Builder, running in your slave. Keep an eye on these pages:
 * https://launchpad.dev/builders (builders overview)
 * https://launchpad.dev/builders/bob (Bob the Builder)
 * https://launchpad.dev/builders/bob/+history (build history for Bob the Builder)

/!\ The job currently starts, but does not complete.


== Stuckage ==

We now get as far as the slave doing the job, and seemingly completing it; but the master never quite picks up on this. According to {{{/var/tmp/development-buildd-manager.log}}} the master finds no {{{build_status}}} entry in the slave status.

Watch these logs:
 * {{{/var/log/postgresql/postgresql-8.*-main.log}}}
 * {{{/var/tmp/development-buildd-manager.log}}}
 * On the slave: {{{/var/log/launchpad-buildd/default.log}}}

Translation Templates from Branch

This is an attempt to guide you through a manual test of the nascent mechanism to produce translation templates based on a bzr branch.

It still needs lots of work.

Patches

  • For debugging, edit lib/lp/buildmaster/manager.py and replace logging.INFO with logging.DEBUG.

  • Hitting 545604. In TranslationTemplatesBuildBehavior.updateBuild_WAITING, try replacing this line:

build_status = self.extractBuildStatus(slave_status)

with

build_status = "OK"

Enabling local branch access

mkdir -p /var/tmp/bazaar.launchpad.dev/static
mkdir -p /var/tmp/ppa

There's a bug somewhere in Windmill that may break access to local branches through http. This bug is scheduled to be fixed soon.

To see if this is biting you, look in your Apache error log (/var/log/apache2/error.log) for a traceback ending with something like this (your home directory and the version numbers will vary):

  File "/home/me/canonical/lp-sourcedeps/eggs/windmill-1.3beta3_lp_r1440-py2.5.egg/windmill/dep/_mozrunner/global_settings.py", line 42, in <module>
    def findInPath(fileName, path=os.environ['PATH']):
  File "/usr/lib/python2.5/UserDict.py", line 22, in __getitem__
    raise KeyError(key)
KeyError: 'PATH'

Near the top of the traceback you'll find mention of a Launchpad branch, probably canonical/lp-branches/devel or canonical/lp-branches/trunk. From that branch, remove two imports:

  • From lib/lp/testing/__init__.py remove this import:

from windmill.authoring import WindmillTestClient

  • From lib/canonical/testing/layers.py remove this:

from windmill.bin.admin_lib import (
    start_windmill, teardown as windmill_teardown)

Now restart Apache.

Setting up the testing environment in a branch

  • Create a Launchpad source tree, and cd into it.
  • Substituting your email address, but not one that is also in the sample data, run (parts may fail, but it's probably okay):

make schema
make run_codehosting >/dev/null 2>&1 &
# Wait until that's all up and running...
utilities/start-dev-soyuz.sh
utilities/soyuz-sampledata-setup.py -e <your@email.address>

Preparing the slave

Follow the instructions for setting up a local buildd slave at BuildFarm/TryOutBuildSlave. Skip the part where it tells you to run Launchpad, since you're already running it. You should end up with a shell open in a chroot for your simulated build slave. Keep it running; we're going to use that slave!

Did you obtain the Lucid chroot tarball as described on that page? Good. Give it to your running Launchpad instance and tell it to use it for Lucid:

  scripts/ftpmaster-tools/manage-chroot.py -s lucid -a i386 add -f chroot-ubuntu-lucid.tar.bz2

Making some branch updates to generate templates from

    pushd /tmp
    bzr init bf-test
    cd bf-test
    cat <<EOF >test.c
#include <gettext-po.h>
#include <stdio.h>
main(){puts(_("Hi"));}
EOF
    mkdir po
    echo test.c >po/POTFILES.in
    bzr add test.c
    bzr add po
    bzr add po/POTFILES.in
    bzr commit -m "Setting up fake intltool branch."
    bzr push lp://dev/bf-test --remember --use-existing-dir
    popd
  • Back in your branch: make sync_branches

Now you should have a TranslationTemplatesBuildJob sitting in the BranchJob table. You should see a very wide line of data coming out of:

psql launchpad_dev -c '
    select *
    from branchjob
    join job on job.id=branchjob.job
    join buildqueue on buildqueue.job=job.id
    where branchjob.job_type=6
    order by job.id'

It will show a branch_url parameter to be passed to the slave, pointing to your branch: http://bazaar.launchpad.dev/~ppa-user/bf-test/bf-test

/!\ Some system setups apparently can't access this branch. Try this:

pushd /tmp
bzr export export-experiment http://bazaar.launchpad.dev/~ppa-user/bf-test/bf-test

If that succeeds and creates a copy of bf-test in a directory called export-experiment, then it's fine; otherwise, re-do your rocketfuel setup by running rocketfuel-setup. And remove your branch. And start over. Sorry!

Simulating a builder

Now we tell Soyuz that your local buildd slave is in fact Bob the Builder.

Logged in as an admin (I suggest using a different browser so as not to break your ongoing session), check the Virtualized checkbox at https://launchpad.dev/builders/bob/+edit and enter an arbitrary hostname under Virtual Machine Host. Clear the "Builder State OK" checkbox to convince it not to continue building firefox for hoary, as it's been trying to do for the past few years.

Submit. Wait for a few seconds. Go back to the form and re-check "Builder State OK." Submit.

Running the job on the slave

After a while, the buildd master should dispatch your job to Bob the Builder, running in your slave. Keep an eye on these pages:

/!\ The job currently starts, but does not complete.

Stuckage

We now get as far as the slave doing the job, and seemingly completing it; but the master never quite picks up on this. According to /var/tmp/development-buildd-manager.log the master finds no build_status entry in the slave status.

Watch these logs:

  • /var/log/postgresql/postgresql-8.*-main.log

  • /var/tmp/development-buildd-manager.log

  • On the slave: /var/log/launchpad-buildd/default.log

Cleanup

To undo the changes made by utilities/soyuz-sampledata-setup.py:

  • rm -f /var/tmp/zeca/*

  • make schema

Translations/GenerateTemplatesOnLocalBuildFarm (last edited 2019-05-28 23:55:19 by cjwatson)