Some Notes on building packages
A developer must be able to make a build in one step. Ideally he should be able to type build <> <> and have a build happen with no further intervention. By making the developer only type one command we greatly reduce the chance that a step will be forgotten, done out order or otherwise messed up.
We should not refer to a build by a SHA but by a meaningful version number, for example "1.3.2" or "1.3.2RC1" for a release candidate build.
When building a given version we must get consistent results. Furthermore we must be able to say that for each project and version there exists a known SHA1 hash. If version 0.8.6 of the xray_web project when built has sha 2fd4e1c67a2d28fced849ee1bb76e7391b93eb12 then if we try to build version 0.8.6 again three years later it should still give the same sha1.
We may also choose to make incremental builds for test servers, that are not tracked, but these should only be for testing and development, not for distribution to customers.
That is to say that they need to be built using git repositories, improvements should come via pull request.
For every project we should have a second "build" repository with a consistent naming scheme. That is to say for the xray_web project the build scripts should live in the repo xray_web_build.
In this repo we should have all the mechanism for doing that build.
we will use open source erlang packages like boss_db, cowboy, jsx etc. We need to be able to create packages from an open source erlang package that has been built with rebar.
In addition erlang packages tend to have dependencies, for example the boss_db package has 26 external dependencies. (see list)
App | Version | Url |
---|---|---|
aleppo | TAG bef139e4c7 | git://github.com/ChicagoBoss/aleppo.git |
bson | TAG 6d3cc910ea | git://github.com/mongodb/bson-erlang.git |
ddb | TAG HEAD | git://github.com/Concurix/ddb.git |
dh_date | REV HEAD | git://github.com/zotonic/dh_date.git |
epgsql | TAG 7b6c71e | git://github.com/mabrek/epgsql.git |
erlando | REV HEAD | git://github.com/travelping/erlando.git |
erlmc | TAG HEAD | git://github.com/bipthelin/erlmc.git |
ets_cache | BRANCH boss_branch | git://github.com/cuongth/ets_cache.git |
gen_server2 | REV master | git://github.com/hyperthunk/gen_server2.git |
goldrush | TAG 0.1.6 | git://github.com/DeadZen/goldrush.git |
ibrowse | TAG v4.0.2 | git://github.com/cmullaparthi/ibrowse.git |
jsx | BRANCH master | git://github.com/talentdeficit/jsx.git |
lager | TAG 2.0.2 | git://github.com/basho/lager.git |
meck | BRANCH master | git://github.com/eproxus/meck |
medici | BRANCH rebarify | git://github.com/ChicagoBoss/medici.git |
mongodb | TAG ce9bf77902 | git://github.com/ChicagoBoss/mongodb-erlang.git |
mysql | TAG 16cae84b5e | git://github.com/dizzyd/erlang-mysql-driver.git |
pmod_transform | REV HEAD | git://github.com/erlang/pmod_transform.git |
poolboy | TAG 1.0.0 | git://github.com/devinus/poolboy.git |
proper | REV HEAD | git://github.com/manopapad/proper.git |
protobuffs | TAG 0.8.1 | git://github.com/basho/erlang_protobuffs.git |
redo | REV HEAD | git://github.com/JacobVorreuter/redo.git |
riakc | TAG 1.3.0 | git://github.com/basho/riak-erlang-client |
riak_pb | REV master | git://github.com/basho/riak_pb |
tiny_pq | TAG HEAD | git://github.com/ChicagoBoss/tiny_pq |
uuid | REV master | git://gitorious.org/avtobiff/erlang-uuid.git |
We need to be able to have a script that can take a rebar.config file and create packages for all the dependent packages.
When creating a release we should clone the repo and apply a named tag to that repo. For example when building xray_web version 0.8.6, all all the included projects should be tagged with the tag xray_web_0.8.6. (in many cases it may be that a given commit could have many tags if the software does not change much).