1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
|
[[!tag proposal]]
[[!meta title="Ick git action: multiple repository support"]]
[[!meta author="Lars Wirzenius"]]
[[!meta date="2018-07-07 12:36"]]
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.
[STANDARD APOLLO REFORM]: https://ick-support.liw.fi/d20aa3eb7bb042c2ba3912f8086deef7.html
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|people/dsilvers]] 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.
|
