Hi,
Nicolas Vigier:
I am thinking about a yaml file that look like this:
tbbversions: 3.5.4: type: release build_commit: ada623c4cbc145521980e6bce08611cff7e81cad 3.6-beta-2: type: beta build_commit: ada623c4cbc145521980e6bce08611cff7e81cad
We can put this file in a git repository where all commits are signed (with git commit -S), and the scripts that use it check the signatures when pulling (with git pull --verify-signatures). We can use something like this to do that: https://gitweb.torproject.org/boklm/tor-browser-bundle-testsuite.git/blob/HE...
Then it would work like this:
a script check this version file, and if there is a new version defined in the file that has not been built yet, starts a new build, and upload it to people.torproject.org if the build is successful.
the script that run automated tests check this version file, and when a version defined in this file is available from at least two builders on people.torproject.org, starts running the tests.
What do you think about this ?
hmmm... how do we handle cases like the one with the current beta where we have to rebuild/rebundle things multiple times and it is urgent to get the new bundles out? Even if we get better at it this might still happen in the future. One idea would be to look at the commit in addition to the version. While that might be better it is probably not helping in cases we just want to rebundle things and run the test suite... Might get even more complex if we, say, only need to rebuild the pluggable transport part.
It is actually not necessary to have all bundles available twice on people.tpo (I even doubt it happens very often). Having one and matching sha256sums from a different build should be sufficient.
Apart from that the general idea sounds good to me. It would especially be useful in sending only a mail to tor-qa after the build passes all of our automation tests.
Georg