Avoid useless daily builds with source recipes

Asked by Giovanni Santini

I'm the maintainer of the FreshPluginPlayer daily builds PPA; actually, code commits depends on the upstream maintainer,
that is not me. I wanted to build this package just when needed, so I setted up the versioning as:

...
# bzr-builder format 0.4 deb-version {debversion:packaging}-rev{revno}.{revno:packaging}~git+{git-commit}
...

In such a way useless builds should be avoided (no changes = no build)

I noticed that Launchpad will try to make a daily build even if not needed.
Is there a way to avoid it?
For now, I'll change the code above to:
...
# bzr-builder format 0.4 deb-version {debversion:packaging}-rev{revno}.{revno:packaging}~git+{git-commit}~{date}
...

But I hope there is a way to avoid this... or that it is possible to add it.

Links related:
Source recipe: https://code.launchpad.net/~itachi-san/+recipe/fresh-player-plugin-daily
PPA: https://launchpad.net/~itachi-san/+archive/ubuntu/freshplayerplugin

Question information

Language:
English Edit question
Status:
Solved
For:
Launchpad itself Edit question
Assignee:
No assignee Edit question
Solved by:
Colin Watson
Solved:
Last query:
Last reply:
Revision history for this message
Launchpad Janitor (janitor) said :
#1

This question was expired because it remained in the 'Open' state without activity for the last 15 days.

Revision history for this message
Colin Watson (cjwatson) said :
#2

I'm not totally sure of exactly what you're asking. Are you trying to construct a recipe that will only receive a daily build when the packaging branch changes, and not when the upstream code changes? If so, I'm not aware of a way to do that; recipes were designed mainly to do daily builds of upstream code, and they're always considered stale (and hence in need of a new build) if the upstream branch changes. The nearest approximation would be to just uncheck "Built daily" in the recipe and occasionally request a build manually.

If that isn't what you mean, please clarify.

Revision history for this message
Launchpad Janitor (janitor) said :
#3

This question was expired because it remained in the 'Needs information' state without activity for the last 15 days.

Revision history for this message
Giovanni Santini (itachi-san) said :
#4

@cjwatson:
Colin, what I mean is the following; the first setup I described build properly when there was an upstream change or a packaging one (giving more relevance to upstream).
The problem is that Launchpad's source builds, when setted as 'daily', start even if there were no changes on both sides.
I saw a problem in my PPA because of "duplicated sources upload" and that's logic, because if I use the same upstream and packaging sources, I will build the same package.
In order to avoid this for the next future, I added the "date" tag.
What I mean is that Launchpad could be a little "smarter" so that if there is no change in upstream and packaging sources the build is not attempted.

Sorry for the delay, but I was on holiday.

Revision history for this message
Best Colin Watson (cjwatson) said :
#5

Well, what you describe is already how it's supposed to work: every so often Launchpad checks for recipes marked as "build daily" that haven't been built in the last day and whose underlying (upstream or packaging) branches have changed, and schedules builds of those recipes. "Build daily" certainly doesn't mean that we always schedule a build once per day no matter what.

What can happen occasionally is that there's a race. Let's say that you push a change to one of the relevant branches on Tuesday evening: that will cause the recipe to be marked as stale, and at some point in the next day or so a build will be scheduled. On Wednesday morning you realise you made a mistake and push a correction. But, if you get very unlucky, you can end up pushing your change just as Launchpad was performing the recipe build. In that case it can happen that the build picks up the new version, but Launchpad thinks it performed the build based on the old version and marks the recipe stale, to be built again the next day. The second build will use the same revisions of everything as the previous one, and thus will fail.

At this point I can't actually prove that this is what happened in your case, since it's gone past our retention period for the relevant log files, but it looks quite plausible based on the commit times on https://code.launchpad.net/~itachi-san/fresh-player-plugin/packaging and two of the conflicting recipe builds (https://launchpad.net/~itachi-san/+archive/ubuntu/freshplayerplugin/+recipebuild/951585 and https://launchpad.net/~itachi-san/+archive/ubuntu/freshplayerplugin/+recipebuild/952181).

Now, it would be possible for us to improve this: we perhaps ought to pin recipe builds to the specific branch revisions that Launchpad thinks it has, so that a concurrent push can't race with the build. I'm not sure that this is worth the effort, though. It's quite a rare case - it's only happened once for your recipe, for instance, causing a few failures since there was one build per active series. https://bugs.launchpad.net/launchpad/+bug/931131 is related.

If I were you, I would probably just set the recipe back to the way it was, without the date, and ignore the rare cases where you hit a race and get upload failures.

Revision history for this message
Giovanni Santini (itachi-san) said :
#6

Thanks Colin Watson, that solved my question.

Revision history for this message
Giovanni Santini (itachi-san) said :
#7

Will do as you suggest Colin, hope that the race cases will be rare; if not I will reopen this question.
Thank you very much :)