Binary repo / Continuous integration should run the testsuite

Created by: ollieparanoid

• "lazy reproducible builds" (apks won't be fully reproducible, but all files inside the apks should have the same content, and each apk should contain the same files. the exception is the signature file, which is of course different.)
  • generate a buildinfo.json file with all relevant versions of all dependencies, recursively
  • implement pmbootstrap challenge, which makes sure, that the exact dependencies are installed, rebuilds the package, compares all file's contents inside the apks
  • make sure, that all pmbootstrap packages are reproducible (linux- packages don't work yet, but they are not required for the testsuite. All other packages work.)
  • Merge lazy-reproducible builds into master
• Automatic challenging of every build before publishing:
  • Building and signing on a dedicated machine ("pmbuilder", I wanted to use a libreboot Thinkpad, but that's too much work as of now, might do that later though).
  • That machine gets a dedicated GitHub account (@pmbuilder) and uploads its binaries into pmOS-binary-packages-staging
  • Write a script, that finds the next package, that needs to be updated, builds it, and uploads it to a dedicated repo: pmbuilder
  • Travis CI job, that challenges the build and - on success only - pushes the signed build from @pmbuilder (and not its own build!) to the binary-package-repo, together with the change APKINDEX
• Stabilization phase:
  • pmbootstrap
    • Include the .buildinfo.json file for each package, when releasing it
    • Verify the APKINDEX
      • Usage: pmbootstrap challenge APKINDEX.tar.gz
      • Verify, that all files referenced in the APKINDEX exist in the same folder
      • Verify, that there is no extra file in the repo, that is not mentioned in the APKINDEX
    • Testcases for all challenge related functions
    • Add switch --experimental-binary-pmOS-packages or something, to be used by the Travis CI job until it is stable
    • When a package is up-to-date in the binary repo, install it from there and don't build it locally!
    • Improve the repo description? right now it only says "user". Alpine has the last git commit hash of the aports repo in there, and a meaningful name (e.g. main, community, ...) Upstreamed a parameter for that.
  • pmbuilder:
    • Challenge the APKINDEX.tar.gz, before pushing the changes
  • Travis job:
    • Improve the commit message, that releases a package. To have more transparency, it should include:
      • The Travis CI Job ID, that was run (ideally a link to it)
      • Commit IDs from the following git repos: staging, release, pmbootstrap
      • Generate and display the commit message at the top (so it's easy to verify the information visually) and use it at the bottom when comitting
    • Run pmbootstrap challenge APKINDEX.tar.gz on the (updated!) release APKINDEX file, right before pushing
    • Let the Travis CI job use the binary repository, so it can build packages, that depend on others (Example: gcc-armhf depends on binutils-armhf, musl-armhf, and all armhf arch packages need gcc-armhf)
  • Fill the binary repo with a lot of packages, especially gcc-armhf etc. Fix all bugs, that appear in the process.
  • Rewrite the scripts to use git-lfs instead of just git, so it performs better
• Productive phase:
  • Reset the binary repo for productive usage
  • Use the real GPG key from @pmbuilder for signing from now on (which also gets used to sign @pmbuilder's commits right now)
  • Roll out @pmbuilder's key in the keys folder of pmbootstrap
  • Adjust pmbootstrap to use the repository
  • Finally run the testsuite in continuous integration
  • Rebuild every package with CI, when it gets changed in a pull-request, just like Alpine Linux does it.

(Ideally, parts of this effort could be re-used to make the whole Alpine Linux distribution reproducible at some far point in the future.)