From: Brian Dolbec <dolsen@gentoo.org>
To: gentoo-catalyst@lists.gentoo.org
Subject: Re: [gentoo-catalyst] catalyst changes for improving automation
Date: Tue, 3 Nov 2020 08:04:12 -0500 [thread overview]
Message-ID: <20201103080412.3fd4e5a0@rogue1> (raw)
In-Reply-To: <CAEdQ38H27b86LQ+HBUAmk7njS7-KJvTiqdNczn6mqcB3n7bF7w@mail.gmail.com>
On Mon, 2 Nov 2020 22:44:07 -0500
Matt Turner <mattst88@gentoo.org> wrote:
> The catalyst-auto automation scripts live in a repo separate from
> catalyst. That increases the difficulty of changing catalyst's
> interface, and it doesn't seem to offer any advantages otherwise.
> (Keeping build specs in a separate repo allows them to be updated
> independent of catalyst and that is valuable). Additionally, since the
> primary way catalyst is used is via this automation, it makes sense to
> support this workflow in catalyst directly.
>
> But to get there, there are some changes to catalyst that I think are
> improvements on their own and simplify the path to integrating
> automation capabilities directly into catalyst. That's what I'd like
> to discuss here.
>
I have been thinking for the past few years that the automation could
benefit from using a buildbot to run the stages. In that way it
would set the required variables, run the stages in sequence. Upon
failure, buildbot makes it easy to re-run failed steps from where they
left off. Or initiate unscheduled builds. It also makes it easy to see
detailed logs (by anyone with a browser if the buildbot is public
viewable) of the various steps for debugging, etc..
Perhaps with your new spec file, you add a varialbe that lists the
stages to run in sequence. In that way it would preserve the old
capability of running single stages independantly or a full sequence.
Or perhaps a cli option to override the setting on an unedited spec
file.
ie:
[build.stages]
stage1
stage2
stage3
livecd1
livecd2
sorry, not familiar with toml
In that way a spec file could be edited simply to restart from any
point with a single variable edit without removing unused [build.???]
definitions for the full run. This would be particularly useful when
troubleshooting hidden/delayed stage build fails.
Overall, I do agree that the releng automation scripts capabilities
should be part of the caltlyst repo in order for them to be up-to-date
with catalyst code.
I have limited time and resources lately, so can't help out much until
I get back home (probably Xmas) largely due to covid... I only have
this small laptop and my eyes are not that good to be doing lots of
work on a tiny 14 inch screen and a stage run to take hours instead
of minutes... (yes, I got spoiled with 2 28 inch 4K displays, 16-core
128k ram system at home...)
Brian Dolbec
<dolsen@gentoo.org>
prev parent reply other threads:[~2020-11-03 13:04 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-03 3:44 [gentoo-catalyst] catalyst changes for improving automation Matt Turner
2020-11-03 10:54 ` Daniel Cordero
2020-11-03 18:19 ` Matt Turner
2020-11-04 10:46 ` Daniel Cordero
2020-11-03 18:36 ` Matt Turner
2020-11-03 13:04 ` Brian Dolbec [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20201103080412.3fd4e5a0@rogue1 \
--to=dolsen@gentoo.org \
--cc=gentoo-catalyst@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox