1 |
On Mon, Nov 02, 2020 at 10:44:07PM -0500, Matt Turner wrote: |
2 |
> The catalyst-auto automation scripts live in a repo separate from |
3 |
> catalyst. That increases the difficulty of changing catalyst's |
4 |
> interface, and it doesn't seem to offer any advantages otherwise. |
5 |
> (Keeping build specs in a separate repo allows them to be updated |
6 |
> independent of catalyst and that is valuable). Additionally, since the |
7 |
> primary way catalyst is used is via this automation, it makes sense to |
8 |
> support this workflow in catalyst directly. |
9 |
> |
10 |
|
11 |
What would be more heavily impacted are those users who may not already |
12 |
have infra set up to do builds or just starting out using catalyst for |
13 |
the first time and haven't written their own automation. |
14 |
|
15 |
I suggest prioritising the collection of up-to-date documentation, |
16 |
especially regarding running catalyst manually, since it'll be |
17 |
completely different to the literature that's currently out there. |
18 |
|
19 |
|
20 |
> But to get there, there are some changes to catalyst that I think are |
21 |
> improvements on their own and simplify the path to integrating |
22 |
> automation capabilities directly into catalyst. That's what I'd like |
23 |
> to discuss here. |
24 |
> |
25 |
> I'd like to: |
26 |
> |
27 |
> 1) Replace the custom .spec file format with TOML |
28 |
> |
29 |
|
30 |
Fine. Aside from the extra quotes and commas, I'd be happy with any well |
31 |
defined format that can handle strings and lists properly. |
32 |
|
33 |
> 2) Combine .spec file sequences (e.g., stage1 -> stage2 -> stage3 -> |
34 |
> livecd-stage1 -> livecd-stage2) into a single file. I suggest naming |
35 |
> this a ".build" file. This will also allow us to remove the redundant |
36 |
> information that currently has to be specified in stage1.spec, |
37 |
> stage2.spec, stage3.spec, like rel_type, version, profile, etc. It |
38 |
> also means that we remove the nonsensical ability to change settings |
39 |
> from one stage to the next that should not change (e.g., rel_type, |
40 |
> version). |
41 |
> |
42 |
|
43 |
How would a target that depends on a different rel_type work? Forks in |
44 |
the dependency tree. |
45 |
|
46 |
> 3) Add ability to denote which stage builds produce artifacts we care |
47 |
> about (and want to save and/or upload) and which are just temporary. |
48 |
> If they're temporary (e.g., a stage1 build) we can delete the artifact |
49 |
> after the build sequence has no further use of it, and we can skip |
50 |
> compressing the result, etc. |
51 |
> |
52 |
|
53 |
This feature should (haven't tested) already exist - it's just not |
54 |
documented. |
55 |
|
56 |
compression_mode: rsync |
57 |
options=['seedcache'] |
58 |
|
59 |
or don't call 'capture' and/or 'remove_chroot' in action_/finish_sequence. |
60 |
|
61 |
> |
62 |
> To that end, I'm starting by figuring out what I would like the new |
63 |
> spec file format to look like. Below are some open questions and then |
64 |
> a strawman new-style spec file. |
65 |
> |
66 |
> • The .spec files in releng.git are really templates that are not |
67 |
> directly usable without sed'ing @REPO_DIR@ and @TIMESTAMP@. It would |
68 |
> be nice if they were directly usable as that would reduce confusion |
69 |
> from users. |
70 |
> • Can we make them directly usable? |
71 |
> • Perhaps we can make catalyst handle the replacements directly? |
72 |
> • Calculating @TIMESTAMP@ is trivially doable—we do it today (see below) |
73 |
|
74 |
Maybe a strftime() template, or even fstring-like tokens? |
75 |
(e.g. "{year}-{month}-{day}") |
76 |
|
77 |
> • We could configure @REPO_DIR@ in catalyst.conf and let catalyst |
78 |
> do the replacement, or we could just make the field relative to some |
79 |
> path specified in catalyst.conf? |
80 |
> |
81 |
|
82 |
While nice to have, I don't agree with locking users into a particular |
83 |
repository layout. |
84 |
|
85 |
> • In the current automation scripts, we generate a value for |
86 |
> @TIMESTAMP@ from the git HEAD used in creating the snapshot. |
87 |
> • Would be nice to remove the dependence on the squashfs snapshot |
88 |
> generation—not difficult to do |
89 |
> |
90 |
|
91 |
I have no comment on this. |
92 |
|
93 |
> • Can we generate and upload a .build file with replacements done to |
94 |
> make stage builds more easily reproducible? Seems easy. |
95 |
> |
96 |
|
97 |
These can just be artifacts from the build. |