Skip to content

Latest commit

 

History

History
90 lines (67 loc) · 2.45 KB

README.mkd

File metadata and controls

90 lines (67 loc) · 2.45 KB
Raw

Glitter

This is an erlang binding to gitolite. It is an abstraction to provide flexibility in case we need to swap gitolite for something else. It was originally part of a larger cloud project that provide basic cloud app/deployment workflow, similar to what Heroku offers (Heroku.com for details).

Basic setup

Glitter runs as either an erlang demaen process or under erlang shell.

This plugin depends on erlang and openssh. Please ensure these dependency be setup beforehand. Only tested using Erlang R14B or above.

Installation

  • make clean
  • make install
  • for dependency like edown (generate git mark down), you need erlang source package (erlang_src in ubuntu) to get it compile.

Basic usage

  • Creating Orgnization
  • Creating New Repo
  • Removing Existing Repo
  • Createing New Repo Branch
  • Removing Existing Repo Branch
  • Adding membership and membership rights on a Repo/ Repo Branch
  • Removing membership and membership rights on a Repo/ Repo Branch

Sample Erlang client call code

Development

It is recommend that you set up your own git server and gitolite to test it out on integeration level; preferrably sending command from a separate client machine. Passing/Failing unit tests may not be sufficient to weed out account/process/file ownership issues.

Parse and write configs for the gitolite admin repositories.

Architecture

Glitter is an erlang application. It consists of three levels. Starting from outmost layer - module glitter - act as a gateway to serve client proper erlang messages; special message formats are assumed to have already properly transformed in prior stage.

Source Code arrangement

Top level Glitter Application --deps (dependency) --ebin (erlang binary) --rel (erlang release configs, metadata files, scripts, release bin) --src (all the subordinate apps)

  • glitter supervisors, applications code -- priv (private files) -- include (state modelled as records, defines etc) <> -- utility (common utility library as an app) --src --include --test -- gl_admin (managment related functions) <>

--test (integeration tests on top app level) --sample (sample client code) *README, rebar, other scripts etc

Status

Parsing is functional. Writing is functional.

No support for branch/directory-specific permissions in repositories. At the moment, I don't really have a need for it, so it probably won't get worked on.