Translation template build jobs should use the new BuildFarmJob

Thinks like this would ideally generate an OOPS.

This is a known issue. It's happening because the Translations jobs are not yet converted to the "new" BuildFarmJob style (and thus have no history in the builders).

Deliberately, it's not an oops.

Hopefully Danilo/Jeroen are going to fix this soon :)

|Julian, I thought we did everything that's "on our side" to unblock Soyuz guys to fix everything that's remaining: i.e. we do construct "new" objects. If I understood correctly, ".build" reference is from the old model and we never used (or provided) it in Translations.

 status new

On Monday 13 December 2010 14:21:51 you wrote:
> |Julian, I thought we did everything that's "on our side" to unblock
>
> Soyuz guys to fix everything that's remaining: i.e. we do construct
> "new" objects. If I understood correctly, ".build" reference is from the
> old model and we never used (or provided) it in Translations.

Hi

The work that needs doing is all Translations-side, the build farm was
prepared and ready for this change a while ago, and Aaron changed the Code
jobs to use the new schema.

The .build reference is available on the new-style schema only, which is why
it fails for Translations.

Ok, so this is my take on what the problem might be:

 - Translations currently implements TranslationTemplatesBuild which is the "new model" class (BuildFarmJobDerived-class)
 - Translations currently uses only the old-style class based on BuildFarmJobOldDerived in TranslationTemplatesBuildJob
 - There is no link between the two
 - Builder.getCurrentBuildFarmJob() tries to get the "new" class by following the "build" from the old-style TranslationTemplatesBuildJob class; i.e. in traceback above, self.currentjob.specific_job is an instance of TranslationTemplatesBuildJob (old-style)

To fix the above, we can either get TranslationTemplatesBuild directly when job_type == translations, or we can hack that into old-style TranslationTemplatesBuildJob.

Ideally, if everything else already supports the new model, we would just switch the implementation of getCurrentBuildFarmJob() to get new-style classes for everything directly, thus allowing us to get rid of the old code.

Hi Danilo,

As far as I'm aware, the specific_job attribute was added as an attribute on IBuildQueue, as a way for a build queue item to return the specific *old-style* build farm job (ie. a model which just linked a Build with a Job). I say as far as I'm aware as it's not code that I wrote (I think Muharem added this), but I did have to move it around. So here's what I know - hope it helps (sorry if I'm just re-stating stuff you already know):

You'll see that the implementation calls IBuildFarmJobOld.getByJob(), and the other implementations of this are used by the classes SourcePackageRecipeBuildJob (Code) and BuildPackageJob (soyuz), both of which just link Job<->Build. These are the objects currently returned by specific_job. But for translations, the equivalent model is TranslationTemplatesBuildJob which *doesn't* link a build at all (in fact, it seems to link job<->branch (BranchJobDerived). That is an error with the current code - AIUI specific_job should be returning something that links job<->build.

But as you note, it may now be possible to switch all the builds over and get rid of the BFJOld stuff (and specific_job) for ever (yay). I'm not in a position to comment there (I haven't been following the code changes for a while), but William is probably a good bet to know if this is now possible.

Hope that helps!

Ok, after discussing with William, we agreed that it should be enough to provide TTBJ.build which points to TTB. Not sure we can do this without the DB schema change, but I am trying to figure this out now.

While trying to read the code around this, I was a bit annoyed (that's an understatement) that TTBJ is both a branch and a build farm job. I've filed that as a separate bug 691530 about cleaning that up.

Fixed in stable r12098 <http://bazaar.launchpad.net/~launchpad-pqm/launchpad/stable/revision/12098>.

The fix doesn't break anything, but it also doesn't quite fix the issue: TTBJ.build isn't on any interface, so buildd-manager still gets a ForbiddenAttribute. After adding that it works OK, so this can roll out for now, and I'll land a fix for the interface shortly.

William, I am assuming you have fixed the interface error. If not, please re-open the bug.

Fixed in stable r12143 <http://bazaar.launchpad.net/~launchpad-pqm/launchpad/stable/revision/12143>.