Diff for "Translations/GenerateTemplatesOnTestServers"

Not logged in - Log In / Register
Differences between revisions 5 and 7 (spanning 2 versions)
⇤ ← Revision 5 as of 2010-04-20 09:18:43 →
Size: 1817
Editor: jtv
Comment:
← Revision 7 as of 2010-04-20 09:33:59 → ⇥
Size: 2958
Editor: jtv
Comment:
Deletions are marked like this. Additions are marked like this.
Line 15: Line 15:
=== Firewall ===

The slaves in the `dogfood` build farm must be allowed to make `http` connections to whatever codehosting server you will be using.

'''TODO: Ensure this—[[Bug:499407|bug 499407]].'''
Line 20: Line 27:
 * Being enabled for `staging`. '''TODO: what production-configs revision? How will we know it's landed?'''  * Being enabled for `staging`.  '''TODO: what `production-configs` revision? How will we know it's landed?'''
Line 27: Line 34:
Make sure you have a branch that is pottery-compatible. (We call the code that generates templates from code "pottery"). Make sure you have a branch that is pottery-compatible. (We call the code that generates templates from code "pottery").  For testing, it should normally ''not'' contain any `.pot` files. Otherwise we'd just end up importing those instead of ones we generated.
Line 35: Line 42:
'''TODO: Find good real-world sample branch for testing—preferably small but with multiple templates.''' '''TODO: Find a good real-world sample branch for testing—preferably small but with multiple templates.'''
Line 42: Line 49:
Set up a product series on `staging` and `dogfood`. Set up a product series on both `staging` and `dogfood`.
Line 44: Line 51:
Set up a pottery-compatible branch on `staging`. Set up a pottery-compatible branch on `staging`; set it as the product series' development branch.

''Register'' a branch on `dogfood`, but do not push it (as `dogfood` has no codehosting). Set it as the product series' development branch.

Configure translation template imports for both product series.

Push a change to your branch on staging. Wait for it to be scanned.

Once the job is scanned, a triplet of matching records should appear in the staging database: a {{{BranchJob}}}, a {{{Job}}}, and a {{{BuildQueue}}}. They are matched on {{{BranchJob.job}}}, {{{Job.id}}}, and {{{BuildQueue.job}}}. In SQL it should be near the top of...
{{{
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 DESC
}}}

Trying out template generation on dogfood/staging

Right now we have no good test platform for this: staging has no build farm, and dogfood has no codehosting. Expect this page to change a lot as we work and learn. We already have pages about doing this on a development system that may also help.

Approach

For now, we'll have to live with a split test setup:

  • Push changes to generate jobs on staging.

  • Copy the jobs over to the dogfood database.

  • Let the dogfood build farm generate the templates.

Checklist

Firewall

The slaves in the dogfood build farm must be allowed to make http connections to whatever codehosting server you will be using.

TODO: Ensure this—bug 499407.

Config

Make sure that generating templates is enabled in the Launchpad lazr config.

  • Enabled for dogfood.

  • Enabled on development systems.

  • Being enabled for staging. TODO: what production-configs revision? How will we know it's landed?

The configuration item in question is generate_templates in the [rosetta] section.

Suitable branches

Make sure you have a branch that is pottery-compatible. (We call the code that generates templates from code "pottery"). For testing, it should normally not contain any .pot files. Otherwise we'd just end up importing those instead of ones we generated.

We don't yet know for sure what real-world branches will work right out of the box. We must fix that!

According to wgrant, editing configure.ac to set GETTEXT_PACKAGE ("or something like that") does the trick.

TODO: Easy litmus test to see if a branch will work with pottery.

TODO: Find a good real-world sample branch for testing—preferably small but with multiple templates.

Once you have a suitable branch, you can copy it to staging's codehosting using "bzr push -d lp:<branch> lp://staging/<branch> --use-existing-dir"

Procedure

Set up a product series on both staging and dogfood.

Set up a pottery-compatible branch on staging; set it as the product series' development branch.

Register a branch on dogfood, but do not push it (as dogfood has no codehosting). Set it as the product series' development branch.

Configure translation template imports for both product series.

Push a change to your branch on staging. Wait for it to be scanned.

Once the job is scanned, a triplet of matching records should appear in the staging database: a BranchJob, a Job, and a BuildQueue. They are matched on BranchJob.job, Job.id, and BuildQueue.job. In SQL it should be near the top of... 

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 DESC

Translations/GenerateTemplatesOnTestServers (last edited 2020-09-17 12:48:23 by cjwatson)