LP unable to build snap from a git tag

Bug #1687078 reported by Adam Stokes
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Launchpad itself
Invalid
High
Unassigned
fix_quantity_reordering_rules
Invalid
Undecided
Unassigned
launchpad-buildd
Fix Released
High
Colin Watson

Bug Description

Attempted to build a snap from git tag and it failed with the following:

fatal: Remote branch refs/tags/2.2.0-beta3 not found in upstream origin

https://launchpadlibrarian.net/317473221/buildlog_snap_ubuntu_xenial_arm64_conjure-up-2.2-beta3_BUILDING.txt.gz

Thanks!

Tags: lp-snappy

Related branches

Revision history for this message
Colin Watson (cjwatson) wrote :

This requires fixes on both the build manager and worker sides, essentially because "git clone -b" only accepts branch names rather than general tag names so we need to work around it.

tags: added: lp-snappy
Changed in launchpad:
status: New → Triaged
importance: Undecided → High
Changed in launchpad-buildd:
status: New → Triaged
importance: Undecided → High
Revision history for this message
Colin Watson (cjwatson) wrote :

Actually I just noticed that "git clone -b" does take tag names after all - it's just a bit weird because it only accepts their shortened form (so it's ambiguous in a corner case that probably doesn't matter). That means we don't need to change the build manager side.

Changed in launchpad:
status: Triaged → Invalid
Changed in launchpad-buildd:
status: Triaged → In Progress
assignee: nobody → Colin Watson (cjwatson)
Colin Watson (cjwatson)
Changed in launchpad-buildd:
status: In Progress → Fix Committed
Revision history for this message
Colin Watson (cjwatson) wrote :

Fixed in launchpad-buildd 162, now on production.

Changed in launchpad-buildd:
status: Fix Committed → Fix Released
Revision history for this message
Benjamin Bach (benjaoming) wrote :

Whereas branches are very obviously intended for a "latest" pull without any further verification, it's important to note about git tags:

They can be edited.

This of course will not guarantee reproducible builds, for whatever reason they would be idealized.

However, for malicious purposes: If you tag something "v1.2.3" and then have it built and released with some backdoor, it's easy to cover up the tracks by force-pushing and overwriting the tag.

Therefore, as I understand it, git commit hashes are the safer alternative. They cannot be changed - they can be deleted of course, but not changed.

Eduardo (eddy89)
Changed in launchpad:
status: Invalid → Fix Committed
Colin Watson (cjwatson)
Changed in fix:
status: New → Invalid
Changed in launchpad:
status: Fix Committed → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.