[tbb-dev] TBB versions file

[Nicolas Vigier]

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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tbb-dev/attachments/20140411/087921d6/attachment.sig>