Code review comment for lp:~cjwatson/launchpad/snap-build-record-code
Revision history for this message
| Colin Watson (cjwatson) wrote | # |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
0e1f616
(Get the code!)
There are a couple of known problems with this, discussed on today's LP team call:
(1) When the snap build is detached, it will no longer have a private code artifact attached to it and thus may become public. Oops.
(2) It's not obvious that these are quite the semantics we want. Unlike source packages, Git repositories include history, but the history can be mutated (e.g. via git filter-branch), and the process of making a private repository public might well include redacting its history. If old snap builds automatically become public then that could be a problem.
We may need a private flag on the build, but it probably can't just be that because we need some way of knowing who can see it. Perhaps we could detach from public builds (thus keeping logs for old builds that are on public Ubuntu images, etc.) but delete private builds. Perhaps only the snap owner could see old detached private builds, or maybe even only admins. Or something else ...