Recovery tarballs for snap builds
Bug #1763639 reported by
Cris Dywan
This bug affects 1 person
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Launchpad itself |
Fix Released
|
High
|
Colin Watson | ||
launchpad-buildd |
Fix Released
|
High
|
Colin Watson |
Bug Description
Launchpad should have a mechanism to fetch all sources required to build a snap and store the result of it. A branch can then be created from it to allow future re-builds of the same snap and applying patches on top of the branch as necessary.
This would be achieved by essentially separating out the "snapcraft pull" step during the build, which retrieves all external dependencies, and creating a copy of the result for later use.
Related branches
lp:~cjwatson/launchpad-buildd/snap-source-tarball
- William Grant (community): Approve (code)
-
Diff: 205 lines (+104/-10)5 files modifieddebian/changelog (+2/-0)
lpbuildd/snap.py (+16/-8)
lpbuildd/target/build_snap.py (+11/-0)
lpbuildd/target/tests/test_build_snap.py (+24/-0)
lpbuildd/tests/test_snap.py (+51/-2)
lp:~cjwatson/launchpad/db-snap-source-tarball
- William Grant (community): Approve (db)
- Stuart Bishop: Pending (db) requested
-
Diff: 14 lines (+10/-0)1 file modifieddatabase/schema/patch-2209-83-2.sql (+10/-0)
lp:~cjwatson/launchpad/snap-source-tarball
- William Grant (community): Approve (code)
-
Diff: 388 lines (+91/-9)11 files modifiedlib/lp/snappy/browser/snap.py (+4/-0)
lib/lp/snappy/browser/tests/test_snap.py (+27/-0)
lib/lp/snappy/interfaces/snap.py (+7/-0)
lib/lp/snappy/model/snap.py (+10/-4)
lib/lp/snappy/model/snapbuildbehaviour.py (+1/-0)
lib/lp/snappy/templates/snap-edit.pt (+4/-0)
lib/lp/snappy/templates/snap-index.pt (+9/-0)
lib/lp/snappy/templates/snap-new.pt (+3/-0)
lib/lp/snappy/tests/test_snap.py (+4/-0)
lib/lp/snappy/tests/test_snapbuildbehaviour.py (+14/-0)
lib/lp/testing/factory.py (+8/-5)
tags: | added: feature lp-snappy |
Changed in launchpad: | |
status: | New → Triaged |
importance: | Undecided → High |
Changed in launchpad-buildd: | |
status: | New → Triaged |
importance: | Undecided → High |
Changed in launchpad-buildd: | |
status: | Triaged → In Progress |
assignee: | nobody → Colin Watson (cjwatson) |
Changed in launchpad: | |
status: | Triaged → In Progress |
assignee: | nobody → Colin Watson (cjwatson) |
tags: |
added: qa-ok removed: qa-needstesting |
Changed in launchpad-buildd: | |
status: | In Progress → Confirmed |
Changed in launchpad-buildd: | |
status: | Confirmed → In Progress |
Changed in launchpad: | |
status: | Fix Committed → Fix Released |
To post a comment you must log in.
We need to specify this in a great deal more detail; it's not actionable until we do. Things I can think of right now include:
* Is the "branch" part truly necessary, as opposed to simply creating a tarball that somebody can then later unpack and drop into a branch if necessary? The latter is a lot easier - we don't have many of the mechanisms we'd need to create a branch at this point, and although they could no doubt be built, there are many other non-obvious things here such as how to specify the branch ownership, whether it should be Bazaar or Git, etc.
* snapcraft.yaml often specifies remote branches / artifacts / etc. to fetch. How would we suppress this behaviour for a subsequent rebuild? Would we need to produce an edited version of snapcraft.yaml?
* The output of "snapcraft pull" isn't likely to be anyone's preferred form for modification. Have there been any experiments done on the snapcraft side to work out what the workflow would actually look like for developers? I think this sort of thing needs to come before implementation in launchpad-buildd.
* Exactly what files and directories need to be saved from the "snapcraft pull" step in order that snapcraft won't try to re-fetch them in a later step? What must we, or indeed developers working with the output, avoid doing so that snapcraft won't decide that it needs to pull again?