Merge lp:~jibel/ubuntu-cdimage/support_for_multilayer into lp:ubuntu-cdimage
Status: | Merged |
---|---|
Merged at revision: | 1792 |
Proposed branch: | lp:~jibel/ubuntu-cdimage/support_for_multilayer |
Merge into: | lp:ubuntu-cdimage |
Prerequisite: | lp:~vorlon/ubuntu-cdimage/prune-obsolete-code |
Diff against target: |
358 lines (+130/-81) (has conflicts) 5 files modified
etc/crontab (+1/-1) etc/livefs-launchpad (+1/-0) etc/qa-products (+1/-0) lib/cdimage/livefs.py (+43/-46) lib/cdimage/tests/test_livefs.py (+84/-34) Text conflict in etc/purge-days |
To merge this branch: | bzr merge lp:~jibel/ubuntu-cdimage/support_for_multilayer |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Steve Langasek | Approve | ||
Review via email: mp+364105@code.launchpad.net |
This proposal supersedes a proposal from 2018-11-26.
Commit message
Adds support for multilayer images
* Made artefacts download generic: Don't hardcode artefact names and ensure they can be matched via regexp, on launchpad or local directory build.
* Fixed test suite
* Removed obsolete edubuntu server-squashfs test (LP: #1154601)
* Ensure we are still compatible with tests using a local server and with a local build.
* Add new ubuntu:canary subproject in automated builds
Extract from the discussion with cjwatson about these changes:
"""""
didrocks hey cjwatson! jibel and I have a question on ubuntu-cdimage: as with the new layered images we are building, we might not know in advance the squashfs, size, manifest files. We want to avoid to hardcode more filenames that already exists. In livefs.py, there are basically 2 code paths to download assets. One is using LP API (and so, can list all artefacts attached to a specific build) and the other
didrocks one is just for filesystem + http:// download. We thought to match against regexp, which works in the LP case and for filesystem (via os.listdir()). However, tests are failing as they are using http mock server. I wonder if in production, only the LP path is took. If so, can we just detect "http" for tests and either create a manifest that we download or rely on hardcoded filenames?
cjwatson As far as I know it's only ever the LP path in production, indeed
didrocks so, do you think special casing tests, like not using the regexp for them, is fine?
cjwatson Yeah, I think so
didrocks perfect! Thanks a lot cjwatson :)
cjwatson The http:// case may even be legacy - not sure
didrocks yeah, sounds like it, but we preferred asking you directly :)
cjwatson Obviously for good software engineering reasons keeping special cases for tests to a minimum is a good idea, but creating a sort of meta-manifest doesn't seem unreasonable, maybe with a fallback if it doesn't exist
didrocks yeah, the best would be ofc to rewrite the tests to mock LP
didrocks but I think that's out of our current scope :)
"""""
Description of the change
This is the support for multi layer images based on dead code removal branch from from Steve.
Rebased on trunk, could you please review? Thanks