This is a proposal to change ick's git action to support multiple repositories. It's been discussed on IRC and on the ick-discuss mailing list: ticket STANDARD APOLLO REFORM. This page is based on those discussions.

Status quo

Currently the git action works like this: the user sets the project parameters git_url and git_dir, and uses the git action in a pipeline:

- action: git
  where: host

The git_url specifies the repository URL and git_dir specifies the directory relatvie to the workspace where the repository is to be cloned. The git action does the network operations needed to clone the repository (if the git_dir directory doesn't exist), or to update an existing clone (if it does), by git remote update.

This is an action that's run on the host, not in a container, for two reasons:

  • it has access to the worker's SSH key, and so can access private repositories

  • it is expected that in the future anything that runs in the container will have no network access at all

The git action is meant to be followed by a shell or Pythona action, run in a container, which checks out the ref in the git_ref parameter.

Problems with the status quo

Status quo works, but only for single-repository projects. Daniel would like to use multiple repositories. His specific use case is that he separates the upstream part and the Debian packaging parts of his projects into separate repositories (or separate branches of the same repository). Additionally, his projects share build scripting, which are yet another git repository.

Lars notes that this is probably not a use case unique to Daniel and it would be good for ick to support constructing the workspace from any number of repositories.

Proposal

Change the git action to expect a project parameters git and git_defaults. The former is a list of key/value pairs (dicts), and the latter gives defaults for keys not specified in those dicts. Example:

- project: foo
  parameters:
    git_defaults:
      repo_base: git://git.example.com/
      ref: master
    git:
    - repo: foo.git
      dir: src
    - repo: foo/debian.git
      dir: src/debian
      ref: debian/unstable
    - repo: git://other-git.example.com/scripts.git
      dir: scripts

The git action would construct the following tree in the workspace:

src/            clone of git://git.example.com/foo.git
  .git/
  debian/       clone of git://git.example.com/foo/debian.git
    .git/
scripts/        clone of git://other-git.example.com/scripts.git
  .git/

In the dicts in the git parameter, if repo is a relative URL, it is joined with the repo_base value from git_defaults, or from the same variable in the same git dict.

Again, the git action only does the operations requiring network. It is expected that the user will provide additional shell or Python actions to update the working tree afterwards. Ick will provide such an action, later, when we've honed one to work well.

Backwards compatibility

If there is no git parameter, the git action will look for the git_url and git_dir parameters, and act as if a git parameter is defined with those values:

git_url: git://git.example.com/foo.git
git_dir: src

With these parameters, the git action would pretend as if the folloging parameter exists:

git:
- repo: git://git.example.com/foo.git
  dir: src

Additionally, the git action will add to the build log a deprecation warning suggesting the use of the git parameter.