Hi,
On Fri, 11 Apr 2014, Georg Koppen wrote:
Hi,
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.
Ah, I have been thinking about that just after sending the mail. I think we can add a build number in the versions file, in addition to the version number. And when either the version or build number changes, we run the tests again.
So the versions file with build number would be something like this: ---- tbbversions: 3.5.4: type: release build_commit: ada623c4cbc145521980e6bce08611cff7e81cad buildnum: 1 3.6-beta-2: type: beta build_commit: ada623c4cbc145521980e6bce08611cff7e81cad buildnum: 3 ----
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.
Indeed. So the build script should check whether someone already uploaded a matching version and upload only the sha256sums in that case.
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.
Ok, I can make it send an email to tor-qa with the results.