S3 artifact distribution changes

[chayim]

In order to support automated image distribution, and a future of unlimited platforms, we need to change our distribution strategy. Artifact distribution in S3 (i.e tars, ramps, etc.) need to reflect both products, versions, and builds, in such a way that multiple async systems can make use of the artifacts.

The following is the proposed path changes for s3.

s3://redislabs/$PRODUCT/$VERSION/YYYYMMDD

ex: s3://redislabs/redisgears/2.2/01012001/....

These directories in turn will have copies of the latest artifact, meaning that a secondary job exists to promote artifacts from a dated release to latest.

The benefit of this approach is that async processes can push to the same named, destination, in addition to having support for unlimited items that depend on the sort of release structure. Similarly combined/special releases (i.e redisgears with redisjson) can be renamed as if they are a product (i.e redisjsongears or redisfoobar).

At issue with this approach is the specific usage of date, though doing so by date makes this easily sortable. Possible solution to this is to replace the YYYYMMDD date object with YYYYMMDD-, YYYYMMDD-HHMM, or YYYYMMDD-HH-MM-. The added benefit of the latter is that it communicates instantly both the versioned item status, in addition to the git hash - making returning the source code painless, and automatable. Examples include:

approach 1 (YYYYMMDD): s3://redislabs/redisgears/2.2/20010102/

approach 2 (YYYYMMDD-HHMM): s3://redislabs/redisgears/2.2/20010102-1352/

approach 3 (YYYYMMDD-HHMM): s3://redislabs/redisgears/2.2/20010102-1352-abc7df/