public inbox for gentoo-catalyst@lists.gentoo.org
 help / color / mirror / Atom feed
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>


      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