cimas 0.1.0
Sign up to get free protection for your applications and to get access to all the features.
- checksums.yaml +7 -0
- data/.gitignore +11 -0
- data/.rspec +3 -0
- data/CODE_OF_CONDUCT.md +74 -0
- data/Gemfile +4 -0
- data/Gemfile.lock +86 -0
- data/README.adoc +467 -0
- data/Rakefile +6 -0
- data/bin/console +14 -0
- data/bin/setup +8 -0
- data/cimas.gemspec +44 -0
- data/exe/cimas +208 -0
- data/lib/cimas.rb +5 -0
- data/lib/cimas/cli/command.rb +500 -0
- data/lib/cimas/version.rb +3 -0
- metadata +144 -0
checksums.yaml
ADDED
@@ -0,0 +1,7 @@
|
|
1
|
+
---
|
2
|
+
SHA256:
|
3
|
+
metadata.gz: 75ee4551ad4b87e20cefd3e07d17b35b705c7a1913120b64c6f7025f584889c6
|
4
|
+
data.tar.gz: 0f215697f7ec882570b362295a4bf61a995ba942069933fe115e8db9625f6755
|
5
|
+
SHA512:
|
6
|
+
metadata.gz: b0e666111cc035476b234f1727811776966508ebef5c4358350097841aa3dad55ac7e757a6ac19bd9161f396277305a64cd5c5c127466f5d7a97b33722f74239
|
7
|
+
data.tar.gz: 55469b83a7561851172d430451379ab87ff5c467034c1562e513ecbd7f34a47874e9178837c39c6c14c0ac1169ef62134733a5d13ea91074b6a8398a4ad1b222
|
data/.gitignore
ADDED
data/.rspec
ADDED
data/CODE_OF_CONDUCT.md
ADDED
@@ -0,0 +1,74 @@
|
|
1
|
+
# Contributor Covenant Code of Conduct
|
2
|
+
|
3
|
+
## Our Pledge
|
4
|
+
|
5
|
+
In the interest of fostering an open and welcoming environment, we as
|
6
|
+
contributors and maintainers pledge to making participation in our project and
|
7
|
+
our community a harassment-free experience for everyone, regardless of age, body
|
8
|
+
size, disability, ethnicity, gender identity and expression, level of experience,
|
9
|
+
nationality, personal appearance, race, religion, or sexual identity and
|
10
|
+
orientation.
|
11
|
+
|
12
|
+
## Our Standards
|
13
|
+
|
14
|
+
Examples of behavior that contributes to creating a positive environment
|
15
|
+
include:
|
16
|
+
|
17
|
+
* Using welcoming and inclusive language
|
18
|
+
* Being respectful of differing viewpoints and experiences
|
19
|
+
* Gracefully accepting constructive criticism
|
20
|
+
* Focusing on what is best for the community
|
21
|
+
* Showing empathy towards other community members
|
22
|
+
|
23
|
+
Examples of unacceptable behavior by participants include:
|
24
|
+
|
25
|
+
* The use of sexualized language or imagery and unwelcome sexual attention or
|
26
|
+
advances
|
27
|
+
* Trolling, insulting/derogatory comments, and personal or political attacks
|
28
|
+
* Public or private harassment
|
29
|
+
* Publishing others' private information, such as a physical or electronic
|
30
|
+
address, without explicit permission
|
31
|
+
* Other conduct which could reasonably be considered inappropriate in a
|
32
|
+
professional setting
|
33
|
+
|
34
|
+
## Our Responsibilities
|
35
|
+
|
36
|
+
Project maintainers are responsible for clarifying the standards of acceptable
|
37
|
+
behavior and are expected to take appropriate and fair corrective action in
|
38
|
+
response to any instances of unacceptable behavior.
|
39
|
+
|
40
|
+
Project maintainers have the right and responsibility to remove, edit, or
|
41
|
+
reject comments, commits, code, wiki edits, issues, and other contributions
|
42
|
+
that are not aligned to this Code of Conduct, or to ban temporarily or
|
43
|
+
permanently any contributor for other behaviors that they deem inappropriate,
|
44
|
+
threatening, offensive, or harmful.
|
45
|
+
|
46
|
+
## Scope
|
47
|
+
|
48
|
+
This Code of Conduct applies both within project spaces and in public spaces
|
49
|
+
when an individual is representing the project or its community. Examples of
|
50
|
+
representing a project or community include using an official project e-mail
|
51
|
+
address, posting via an official social media account, or acting as an appointed
|
52
|
+
representative at an online or offline event. Representation of a project may be
|
53
|
+
further defined and clarified by project maintainers.
|
54
|
+
|
55
|
+
## Enforcement
|
56
|
+
|
57
|
+
Instances of abusive, harassing, or otherwise unacceptable behavior may be
|
58
|
+
reported by contacting the project team at abobrikovich@gmail.com. All
|
59
|
+
complaints will be reviewed and investigated and will result in a response that
|
60
|
+
is deemed necessary and appropriate to the circumstances. The project team is
|
61
|
+
obligated to maintain confidentiality with regard to the reporter of an incident.
|
62
|
+
Further details of specific enforcement policies may be posted separately.
|
63
|
+
|
64
|
+
Project maintainers who do not follow or enforce the Code of Conduct in good
|
65
|
+
faith may face temporary or permanent repercussions as determined by other
|
66
|
+
members of the project's leadership.
|
67
|
+
|
68
|
+
## Attribution
|
69
|
+
|
70
|
+
This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4,
|
71
|
+
available at [http://contributor-covenant.org/version/1/4][version]
|
72
|
+
|
73
|
+
[homepage]: http://contributor-covenant.org
|
74
|
+
[version]: http://contributor-covenant.org/version/1/4/
|
data/Gemfile
ADDED
data/Gemfile.lock
ADDED
@@ -0,0 +1,86 @@
|
|
1
|
+
PATH
|
2
|
+
remote: .
|
3
|
+
specs:
|
4
|
+
cimas (0.1.0)
|
5
|
+
git
|
6
|
+
octokit
|
7
|
+
travis
|
8
|
+
|
9
|
+
GEM
|
10
|
+
remote: https://rubygems.org/
|
11
|
+
specs:
|
12
|
+
addressable (2.4.0)
|
13
|
+
backports (3.16.0)
|
14
|
+
diff-lcs (1.3)
|
15
|
+
ethon (0.12.0)
|
16
|
+
ffi (>= 1.3.0)
|
17
|
+
faraday (0.17.3)
|
18
|
+
multipart-post (>= 1.2, < 3)
|
19
|
+
faraday_middleware (0.14.0)
|
20
|
+
faraday (>= 0.7.4, < 1.0)
|
21
|
+
ffi (1.12.2)
|
22
|
+
gh (0.15.1)
|
23
|
+
addressable (~> 2.4.0)
|
24
|
+
backports
|
25
|
+
faraday (~> 0.8)
|
26
|
+
multi_json (~> 1.0)
|
27
|
+
net-http-persistent (~> 2.9)
|
28
|
+
net-http-pipeline
|
29
|
+
git (1.6.0)
|
30
|
+
rchardet (~> 1.8)
|
31
|
+
highline (1.7.10)
|
32
|
+
json (2.3.0)
|
33
|
+
launchy (2.4.3)
|
34
|
+
addressable (~> 2.3)
|
35
|
+
multi_json (1.14.1)
|
36
|
+
multipart-post (2.1.1)
|
37
|
+
net-http-persistent (2.9.4)
|
38
|
+
net-http-pipeline (1.0.1)
|
39
|
+
octokit (4.16.0)
|
40
|
+
faraday (>= 0.9)
|
41
|
+
sawyer (~> 0.8.0, >= 0.5.3)
|
42
|
+
pusher-client (0.6.2)
|
43
|
+
json
|
44
|
+
websocket (~> 1.0)
|
45
|
+
rake (10.5.0)
|
46
|
+
rchardet (1.8.0)
|
47
|
+
rspec (3.9.0)
|
48
|
+
rspec-core (~> 3.9.0)
|
49
|
+
rspec-expectations (~> 3.9.0)
|
50
|
+
rspec-mocks (~> 3.9.0)
|
51
|
+
rspec-core (3.9.1)
|
52
|
+
rspec-support (~> 3.9.1)
|
53
|
+
rspec-expectations (3.9.0)
|
54
|
+
diff-lcs (>= 1.2.0, < 2.0)
|
55
|
+
rspec-support (~> 3.9.0)
|
56
|
+
rspec-mocks (3.9.1)
|
57
|
+
diff-lcs (>= 1.2.0, < 2.0)
|
58
|
+
rspec-support (~> 3.9.0)
|
59
|
+
rspec-support (3.9.2)
|
60
|
+
sawyer (0.8.2)
|
61
|
+
addressable (>= 2.3.5)
|
62
|
+
faraday (> 0.8, < 2.0)
|
63
|
+
travis (1.8.10)
|
64
|
+
backports
|
65
|
+
faraday (~> 0.9)
|
66
|
+
faraday_middleware (~> 0.9, >= 0.9.1)
|
67
|
+
gh (~> 0.13)
|
68
|
+
highline (~> 1.6)
|
69
|
+
launchy (~> 2.1)
|
70
|
+
pusher-client (~> 0.4)
|
71
|
+
typhoeus (~> 0.6, >= 0.6.8)
|
72
|
+
typhoeus (0.8.0)
|
73
|
+
ethon (>= 0.8.0)
|
74
|
+
websocket (1.2.8)
|
75
|
+
|
76
|
+
PLATFORMS
|
77
|
+
ruby
|
78
|
+
|
79
|
+
DEPENDENCIES
|
80
|
+
bundler (~> 2.0)
|
81
|
+
cimas!
|
82
|
+
rake (~> 10.0)
|
83
|
+
rspec (~> 3.0)
|
84
|
+
|
85
|
+
BUNDLED WITH
|
86
|
+
2.1.4
|
data/README.adoc
ADDED
@@ -0,0 +1,467 @@
|
|
1
|
+
= Cimas ("`Continuous integration master`")
|
2
|
+
|
3
|
+
== Purpose
|
4
|
+
|
5
|
+
Cimas handles synchronizing CI configuration across multiple repositories.
|
6
|
+
|
7
|
+
When there are many repositories that need to share identical or similar
|
8
|
+
CI (continuous integration) configuration, it is not only cumbersome
|
9
|
+
but error prone to keep these configuration files in sync.
|
10
|
+
|
11
|
+
For example, adding new value to the CI test matrix for multiple repositories
|
12
|
+
should not itself be a chore.
|
13
|
+
|
14
|
+
NOTE: This problem can technically be mitigated if we can externalize and
|
15
|
+
consolidate CI configuration outside of data repositories.
|
16
|
+
However, most CI solutions don't support external configuration
|
17
|
+
(i.e. Travis, GitHub Actions, Appveyor). For GitHub, see:
|
18
|
+
https://github.community/t5/GitHub-Actions/External-workflow-configuration/td-p/33529[GHA external workflow],
|
19
|
+
https://github.community/t5/GitHub-Actions/Call-an-action-from-another-action/td-p/45034[GHA calling another action]
|
20
|
+
|
21
|
+
|
22
|
+
== History
|
23
|
+
|
24
|
+
Cimas was built to synchronize CI configuration across the
|
25
|
+
the http://github.com/metanorma[Metanorma] and
|
26
|
+
http://github.com/relaton[Relaton] repositories.
|
27
|
+
|
28
|
+
We had a hard time managing them individually!
|
29
|
+
|
30
|
+
|
31
|
+
== Installation
|
32
|
+
|
33
|
+
Cimas (and its CLI command, `cimas`) relies on Git.
|
34
|
+
Please ensure `git` is installed on your system.
|
35
|
+
|
36
|
+
Installing is as easy as:
|
37
|
+
|
38
|
+
[source,sh]
|
39
|
+
----
|
40
|
+
gem install cimas
|
41
|
+
----
|
42
|
+
|
43
|
+
Or, by specifying it in your `Gemfile` if you're using Bundler.
|
44
|
+
|
45
|
+
|
46
|
+
== Concepts
|
47
|
+
|
48
|
+
CI configuration file:: file to configure CI behavior of a repository
|
49
|
+
CI configuration master file:: CI configuration file that applies to one or more target repositories
|
50
|
+
CI configuration master directory:: directory (or a repo) where master CI configuration files reside
|
51
|
+
Cimas working area:: local directory where Cimas works within
|
52
|
+
Cimas managed repository:: repository with CI configuration managed by Cimas
|
53
|
+
|
54
|
+
|
55
|
+
|
56
|
+
== Usage
|
57
|
+
|
58
|
+
=== Command line
|
59
|
+
|
60
|
+
Cimas works through the `cimas` executable. `cimas` provides the following sub-commands.
|
61
|
+
|
62
|
+
* `setup`
|
63
|
+
* `sync`
|
64
|
+
* `diff`
|
65
|
+
* `push`
|
66
|
+
* `pull`
|
67
|
+
* `open-prs`
|
68
|
+
* `lint` (disabled right now)
|
69
|
+
|
70
|
+
|
71
|
+
==== Sub-command options
|
72
|
+
|
73
|
+
These options work across all sub-commands:
|
74
|
+
|
75
|
+
* `-d` or `--dry-run`: Does not perform any destructive behavior.
|
76
|
+
* `-v` (disabled for now)
|
77
|
+
|
78
|
+
|
79
|
+
==== `cimas setup`
|
80
|
+
|
81
|
+
The `setup` sub-command sets up the Cimas working area/directory with
|
82
|
+
Git repos cloned as described in your Cimas configuration file
|
83
|
+
(default: `cimas.yml`).
|
84
|
+
|
85
|
+
This command must be run before any other sub-commands are run,
|
86
|
+
and must be run when the repository addresses change
|
87
|
+
within the Cimas configuration file (it will prompt you).
|
88
|
+
|
89
|
+
[source,sh]
|
90
|
+
----
|
91
|
+
cimas setup -f {cimas-config-file} -r {cimas-working-area}
|
92
|
+
|
93
|
+
# e.g.
|
94
|
+
# cimas setup -f cimas.yml -r ~/src/cimas-wd
|
95
|
+
----
|
96
|
+
|
97
|
+
NOTE: This sub-command is considered "`safe`" as it does not
|
98
|
+
alter the state of existing Git repositories within the Cimas
|
99
|
+
working area.
|
100
|
+
|
101
|
+
|
102
|
+
==== `cimas pull`
|
103
|
+
|
104
|
+
The `pull` sub-command resets all the Git repositories to the
|
105
|
+
original `branch` key set per-repo.
|
106
|
+
|
107
|
+
This command should be run before the `cimas sync` command to
|
108
|
+
clean up state.
|
109
|
+
|
110
|
+
[source,sh]
|
111
|
+
----
|
112
|
+
cimas pull -f {cimas-config-file} -r {cimas-working-area}
|
113
|
+
|
114
|
+
# e.g.
|
115
|
+
# cimas pull -f cimas.yml -r ~/src/cimas-wd
|
116
|
+
----
|
117
|
+
|
118
|
+
NOTE: This sub-command is considered "`destructive`" as it
|
119
|
+
resets states of all Git repositories in the Cimas working area.
|
120
|
+
|
121
|
+
|
122
|
+
==== `cimas sync`
|
123
|
+
|
124
|
+
The `sync` sub-command places the necessary CI configuration files,
|
125
|
+
as described in the Cimas configuration file, into the desired
|
126
|
+
repositories.
|
127
|
+
|
128
|
+
After copying the files, Cimas will also stage the changed files
|
129
|
+
to Git.
|
130
|
+
|
131
|
+
This command must be run before the `cimas push` command.
|
132
|
+
|
133
|
+
[source,sh]
|
134
|
+
----
|
135
|
+
cimas sync -f {cimas-config-file} -r {cimas-working-area} \
|
136
|
+
-d {cimas-master-config-dir}
|
137
|
+
|
138
|
+
# e.g.
|
139
|
+
# cimas sync -f cimas.yml -r ~/src/cimas-wd \
|
140
|
+
# -d ~/src/cimas-config
|
141
|
+
----
|
142
|
+
|
143
|
+
NOTE: This sub-command is considered "`destructive`" as it
|
144
|
+
resets states of all Git repositories in the Cimas working area
|
145
|
+
before adding CI configuration files.
|
146
|
+
|
147
|
+
|
148
|
+
==== `cimas diff`
|
149
|
+
|
150
|
+
The `diff` sub-command provides a consolidated `diff` output between
|
151
|
+
the repositories in the Cimas working area and remote.
|
152
|
+
This is useful prior to running the `cimas push` command.
|
153
|
+
|
154
|
+
After copying the files, Cimas will also stage the changed files
|
155
|
+
to Git.
|
156
|
+
|
157
|
+
This command must be run before the `cimas push` command.
|
158
|
+
|
159
|
+
[source,sh]
|
160
|
+
----
|
161
|
+
cimas diff -f {cimas-config-file} -r {cimas-working-area} \
|
162
|
+
-d {cimas-master-config-dir}
|
163
|
+
|
164
|
+
# e.g.
|
165
|
+
# cimas diff -f cimas.yml -r ~/src/cimas-wd \
|
166
|
+
# -d ~/src/cimas-config
|
167
|
+
----
|
168
|
+
|
169
|
+
NOTE: This sub-command is considered "`safe`" as it
|
170
|
+
does not alter state of Git repositories.
|
171
|
+
|
172
|
+
|
173
|
+
|
174
|
+
==== `cimas push`
|
175
|
+
|
176
|
+
The `push` sub-command:
|
177
|
+
|
178
|
+
* commits the changes made by the `sync` sub-command in a new branch;
|
179
|
+
* pushes the new branch to the first Git remote.
|
180
|
+
|
181
|
+
This command must be run before the `cimas open-prs` command
|
182
|
+
as the branches need to be pushed before pull-requests can be
|
183
|
+
opened against them.
|
184
|
+
|
185
|
+
[source,sh]
|
186
|
+
----
|
187
|
+
cimas push -f {cimas-config-file} -r {cimas-working-area} \
|
188
|
+
-b {new-branch-for-commit} \
|
189
|
+
-m {commit-message} \
|
190
|
+
|
191
|
+
# e.g.
|
192
|
+
# cimas push -f cimas.yml -r ~/src/cimas-wd \
|
193
|
+
# -b my-new-ci-branch \
|
194
|
+
# -m 'My commit message' \
|
195
|
+
# [-g {group1,group2,...}]
|
196
|
+
----
|
197
|
+
|
198
|
+
NOTE: This sub-command is considered "`destructive`" as it
|
199
|
+
alters the state of all Git repositories in the Cimas working area
|
200
|
+
by adding commits and branches.
|
201
|
+
|
202
|
+
|
203
|
+
==== `cimas open-prs`
|
204
|
+
|
205
|
+
The `push` sub-command:
|
206
|
+
|
207
|
+
* commits the changes made by the `sync` sub-command in a new branch;
|
208
|
+
* pushes the new branch to the first Git remote.
|
209
|
+
|
210
|
+
Since this command depends on GitHub privileged functionality,
|
211
|
+
you must supply your GitHub Personal Access Token (PAT)
|
212
|
+
via the `GITHUB_TOKEN` environment variable.
|
213
|
+
|
214
|
+
[source,sh]
|
215
|
+
----
|
216
|
+
GITHUB_TOKEN=deadbeefdeadbeef; \
|
217
|
+
cimas open-prs -f {cimas-config-file} -r {cimas-working-area} \
|
218
|
+
-b {new-branch-to-pr} \
|
219
|
+
-m {pr-message} \
|
220
|
+
|
221
|
+
# e.g.
|
222
|
+
# cimas open-prs -f cimas.yml -r ~/src/cimas-wd \
|
223
|
+
# -b my-new-ci-branch \
|
224
|
+
# -m 'My pull-request message' \
|
225
|
+
# [-g {group1,group2,...}]
|
226
|
+
----
|
227
|
+
|
228
|
+
NOTE: This sub-command is considered "`destructive`" as it
|
229
|
+
alters the state of GitHub repositories by creating
|
230
|
+
pull requests.
|
231
|
+
|
232
|
+
|
233
|
+
== Configuration
|
234
|
+
|
235
|
+
=== General
|
236
|
+
|
237
|
+
Cimas relies on reading a Cimas configuration file (default: `cimas.yml`)
|
238
|
+
that specifies:
|
239
|
+
|
240
|
+
* repository settings;
|
241
|
+
* group settings; and
|
242
|
+
* Cimas behavior
|
243
|
+
|
244
|
+
This YAML file needs to be in the following structure:
|
245
|
+
|
246
|
+
[source,yaml]
|
247
|
+
----
|
248
|
+
---
|
249
|
+
settings:
|
250
|
+
{option-key}: {option-value}
|
251
|
+
...
|
252
|
+
|
253
|
+
repositories:
|
254
|
+
{repo-name}:
|
255
|
+
remote: {remote-name}
|
256
|
+
branch: {branch-name}
|
257
|
+
files:
|
258
|
+
{CI-file-target-location}: {CI-configuration-master-file-location}
|
259
|
+
...
|
260
|
+
...
|
261
|
+
|
262
|
+
groups:
|
263
|
+
{group-name}:
|
264
|
+
- {repo-name}
|
265
|
+
- ...
|
266
|
+
----
|
267
|
+
|
268
|
+
|
269
|
+
EXAMPLE: See metanorma/metanorma-build-scripts/cimas-config/cimas.yml for a working configuration.
|
270
|
+
|
271
|
+
|
272
|
+
=== `settings`
|
273
|
+
|
274
|
+
The `settings` object specifies run-time configuration. These options
|
275
|
+
are merged with the command-line options, which have higher priority.
|
276
|
+
|
277
|
+
Syntax:
|
278
|
+
|
279
|
+
[source,yaml]
|
280
|
+
----
|
281
|
+
settings:
|
282
|
+
{option-key}: {option-value}
|
283
|
+
...
|
284
|
+
----
|
285
|
+
|
286
|
+
The following options are available:
|
287
|
+
|
288
|
+
* `reviewers` takes an array of GitHub user names as PR reviewers.
|
289
|
+
This is only relevant to the `cimas open-prs` sub-command.
|
290
|
+
* `assignees` takes an array of GitHub user names as assignees to PRs.
|
291
|
+
This is only relevant to the `cimas open-prs` sub-command.
|
292
|
+
|
293
|
+
|
294
|
+
EXAMPLE: This example comes from metanorma/metanorma-build-scripts/cimas-config/cimas.yml.
|
295
|
+
|
296
|
+
[source,yaml]
|
297
|
+
----
|
298
|
+
settings:
|
299
|
+
reviewers:
|
300
|
+
- opoudjis
|
301
|
+
- ronaldtse
|
302
|
+
----
|
303
|
+
|
304
|
+
|
305
|
+
=== `repositories`
|
306
|
+
|
307
|
+
The `repositories` object specifies all Git repositories
|
308
|
+
that are managed by Cimas under this configuration file.
|
309
|
+
|
310
|
+
For example, when the `cimas setup` command is run, all
|
311
|
+
of these repositories will be cloned under the
|
312
|
+
Cimas working area.
|
313
|
+
|
314
|
+
Each repository is represented by a key under the
|
315
|
+
`repositories` object.
|
316
|
+
|
317
|
+
[source,yaml]
|
318
|
+
----
|
319
|
+
{repo-name-1}:
|
320
|
+
remote: {remote-name}
|
321
|
+
branch: {branch-name}
|
322
|
+
files:
|
323
|
+
{CI-file-target-location-1}: {CI-configuration-master-file-location-1}
|
324
|
+
{CI-file-target-location-2}: {CI-configuration-master-file-location-2}
|
325
|
+
----
|
326
|
+
|
327
|
+
These attributes are mandatory for each repository:
|
328
|
+
|
329
|
+
* `remote`: the remote Git location of this repository (i.e. where `git clone` can find this repository). SSH and HTTPS paths are supported. Single valued.
|
330
|
+
* `branch`: the source branch and eventual branch to commit to (where a PR should be created against). Single valued.
|
331
|
+
* `files`: composed of key value pairs of the "`target file location within the repository`" to the "`master file location within the configuration master directory`". Multiple files are supported.
|
332
|
+
|
333
|
+
Syntax:
|
334
|
+
|
335
|
+
[source,yaml]
|
336
|
+
----
|
337
|
+
repositories:
|
338
|
+
{repo-name-1}:
|
339
|
+
remote: {remote-name}
|
340
|
+
branch: {branch-name}
|
341
|
+
files:
|
342
|
+
{CI-file-target-location-1}: {CI-configuration-master-file-location-1}
|
343
|
+
{CI-file-target-location-2}: {CI-configuration-master-file-location-2}
|
344
|
+
{repo-name-2}:
|
345
|
+
remote: {remote-name}
|
346
|
+
branch: {branch-name}
|
347
|
+
files:
|
348
|
+
{CI-file-target-location-3}: {CI-configuration-master-file-location-3}
|
349
|
+
...
|
350
|
+
...
|
351
|
+
----
|
352
|
+
|
353
|
+
|
354
|
+
EXAMPLE: This example comes from metanorma/metanorma-build-scripts/cimas-config/cimas.yml.
|
355
|
+
|
356
|
+
[source,yaml]
|
357
|
+
----
|
358
|
+
repositories:
|
359
|
+
metanorma-model-gb:
|
360
|
+
remote: ssh://git@github.com/metanorma/metanorma-model-gb
|
361
|
+
branch: master
|
362
|
+
files:
|
363
|
+
.github/workflows/macos.yml: gh-actions/model/macos.yml
|
364
|
+
.github/workflows/ubuntu.yml: gh-actions/model/ubuntu.yml
|
365
|
+
.github/workflows/windows.yml: gh-actions/model/windows.yml
|
366
|
+
----
|
367
|
+
|
368
|
+
=== `groups`
|
369
|
+
|
370
|
+
Cimas offers "`grouping`" functionality to allow you to work with groups
|
371
|
+
of repositories. This is useful if your repositories fall into
|
372
|
+
different categories, e.g. repositories for Ruby code vs C code
|
373
|
+
that have different build routines.
|
374
|
+
|
375
|
+
There is a default group of `all` which applies if no group is specified.
|
376
|
+
|
377
|
+
Groups under the `groups` key are collections of repository names.
|
378
|
+
Each group is represented by a key of the group's name, with
|
379
|
+
names of its repositories as array content.
|
380
|
+
|
381
|
+
One repository may belong to multiple groups.
|
382
|
+
Groups have no bearing on what files to synchronize; the files
|
383
|
+
must be specified per repository in the configuration file
|
384
|
+
under the `repositories` section.
|
385
|
+
|
386
|
+
The `-g` switch in the various commands directly refer to the
|
387
|
+
`{group-name}` specified in the configuration file.
|
388
|
+
|
389
|
+
Syntax:
|
390
|
+
|
391
|
+
[source,yaml]
|
392
|
+
----
|
393
|
+
groups:
|
394
|
+
{group-name-1}:
|
395
|
+
- {repo-name-1}
|
396
|
+
- {repo-name-2}
|
397
|
+
...
|
398
|
+
...
|
399
|
+
----
|
400
|
+
|
401
|
+
|
402
|
+
EXAMPLE: This example comes from metanorma/metanorma-build-scripts/cimas-config/cimas.yml.
|
403
|
+
|
404
|
+
[source,yaml]
|
405
|
+
----
|
406
|
+
groups:
|
407
|
+
model:
|
408
|
+
- metanorma-model-iso
|
409
|
+
- metanorma-model-gb
|
410
|
+
- metanorma-model-standoc
|
411
|
+
----
|
412
|
+
|
413
|
+
|
414
|
+
=== Setting up the CI configuration master directory
|
415
|
+
|
416
|
+
You need to first create the "`CIM configuration directory`".
|
417
|
+
|
418
|
+
Typically you'd create one in Git for better version management.
|
419
|
+
|
420
|
+
For example, with https://github.com/metanorma[Metanorma] repositories,
|
421
|
+
the CIM configuration directory is placed in the https://github.com/metanorma/metanorma-build-scripts[`metanorma-build-scripts`]
|
422
|
+
repository.
|
423
|
+
|
424
|
+
|
425
|
+
=== Setting up the local CIM working area
|
426
|
+
|
427
|
+
CIM requires a local working area to work with managed repositories,
|
428
|
+
using Git's pull and push functionalities.
|
429
|
+
|
430
|
+
This only _needs to be done once_ (locally), then you can reuse
|
431
|
+
this working area for future CI configuration updates.
|
432
|
+
|
433
|
+
// `$mn-root`
|
434
|
+
|
435
|
+
You need to create the CIM working area
|
436
|
+
|
437
|
+
Checkout all repositories
|
438
|
+
|
439
|
+
[source,sh]
|
440
|
+
----
|
441
|
+
# suppose the CIM working area is called $CIM_CONFIG_WD
|
442
|
+
mkdir $CIM_CONFIG_WD
|
443
|
+
cd $CIM_CONFIG_WD
|
444
|
+
repo init -u $CIM_CONFIG_REPO
|
445
|
+
repo sync
|
446
|
+
git multi checkout master
|
447
|
+
echo 'metanorma-build-scripts' > .multigit_ignore
|
448
|
+
git clone https://github.com/metanorma/cimas.git
|
449
|
+
cd cimas
|
450
|
+
----
|
451
|
+
|
452
|
+
|
453
|
+
|
454
|
+
|
455
|
+
== Development
|
456
|
+
|
457
|
+
After checking out the repo, run `bin/setup` to install dependencies. Then, run `rake spec` to run the tests. You can also run `bin/console` for an interactive prompt that will allow you to experiment.
|
458
|
+
|
459
|
+
|
460
|
+
== Contributing
|
461
|
+
|
462
|
+
Bug reports and pull requests are welcome on GitHub at https://github.com/metanorma/cimas. This project is intended to be a safe, welcoming space for collaboration, and contributors are expected to adhere to the http://contributor-covenant.org[Contributor Covenant] code of conduct.
|
463
|
+
|
464
|
+
|
465
|
+
== Code of Conduct
|
466
|
+
|
467
|
+
Everyone interacting in the Cimas project’s codebases, issue trackers, chat rooms and mailing lists is expected to follow the https://github.com/metanorma/cimas/CODE_OF_CONDUCT.md[code of conduct].
|