Allow Recipes to be re-used with different base_branch revisions

[Michael Nelson]

Currently the revision of the base branch for a recipe build is specified on the SPRecipe itself (as part of the base_branch specification), but it seems that it would make much more sense (from a users POV), if instead when creating a recipe via the LP UI we always used tip on the recipe (ie. no revision spec on the base branch), and while still allowing the user to specify a revision spec storing it on the SPRBuild.

This would involve adding a base_branch_revision_spec field (or similar) to the SPRBuild table which would be used together with the SPRDataInstruction for the base_branch. As far as i can see, it would give us much more re-usability of recipes (as well as other minor advantages, like not allowing a daily build of a specific base_branch revision to be specified). It would only affect/restrict base_branches of recipes (all other merges in the recipe are free text and so revisions can be specified as needed).

Thoughts? (Idea via beuno's suggestion on mailing list).

[Michael Hudson-Doyle (mwhudson)]

Um, I think the usual value for the sourcepackagerecipedata.revspec for a recipe will be empty, i.e. the tip of the branch will be used.

Maybe I'm being dense on a Friday afternoon, but I don't think there's a bug here.

[Michael Nelson (michael.nelson)]

No, not dense - just a communication failure on my part. Nor is this a bug, but just a thought for a potential optimisation. Feel free to mark it back as invalid, but here's a second attempt to clarify.

So yes, the usual value for the revspec (for the base-branch) will be empty, the question for me is whether that would be best as an attribute on the SPR table, or on the SPRBuild table. Here's a scenario:

1. Joe navigates to his branch foo wanting to build the latest revision to his PPA. He and chooses "Build now".
2. A popup appears and he selects his PPA and clicks Build, selects his packaging branch, specifies the deb version etc., chooses the distroseries etc., names his recipe "foo_with_my_pkging". At the bottom of the overlay he sees an option to select a version of his branch, but he leaves it as Tip.

and everything is fine, until a few days/weeks later, he has a need to build a specific revision of his branch so:

3. Joe navigates back to his branch foo and clicks again on "Build now",
4. He selects his previous recipe "foo_with_my_pkging" (as from his point of view, why should I need a new recipe?)
5. He simply uses the version selector and changes it from Tip to rev 35 and clicks Build.

Now, currently this is not possible, because we store the base branch revision on the SPR record. At step 4., Joe would need to know that he actually needs to create a new recipe specifically for this revision, rather than a build of that recipe at a specific revision. But if instead (at least through the web interface), we *always* created recipes without a revision (ie. the recipe is *always* for tip), and stored a revision spec on the build, it would allow this flexibility.

Does that make sense, or am I talking total crap?

[Michael Nelson (michael.nelson)]

Of course, the above relies on the premise that it would be OK for us to create a recipe based on the SPR but slightly altered with SPRBuild constraints. Maybe that's a bad idea. That is, it's really treating SourcePackageRecipe as a 'base' recipe from which we can derive variants for the SPRBuilds.

It would require us, rather than having ISPR.builder_recipe to instead provide ISPR.getBuilderRecipe(**kwargs).

Is that a really bad thing? Is it an option for us? (as there are other features that seem to be important that would currently rely on this too, like multiple SPRBuilds for different distroseries from the one recipe).

[Michael Hudson-Doyle (mwhudson)]

Dammit, I'm sure I replied to this bug, but it got lost somewhere :(

What you said makes sense, but I think it might be making one use case easy whilst ignoring others. Isn't it possible that you'd want to use a different revno of the packaging branch too? Maybe what you need here is a way to create a one-off recipe for a single build?

[Tim Penhey (thumper)]

OK, as far as I'm aware, we aren't going to actually reuse the recipes but create derived recipes.

[Paul Hummer (rockstar)]

We've talked this over as a team, and I don't think it's a good precedent to allow users to change the recipe on a per-build basis.