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