All of lore.kernel.org
 help / color / mirror / Atom feed
From: Petr Vorel <pvorel@suse.cz>
To: Richard Palethorpe <rpalethorpe@suse.de>
Cc: ltp@lists.linux.it
Subject: Re: [LTP] [PATCH] Add simple Containerfile
Date: Fri, 29 Sep 2023 10:15:21 +0200	[thread overview]
Message-ID: <20230929081521.GA351787@pevik> (raw)
In-Reply-To: <87h6nde7hu.fsf@suse.de>

Hi Richie,

> >> RFC comments:
> >>     * Add git clean -fdX which should remove any build artifacts
> >>       this is different from the suggestion of just doing a check. I just
> >>       found it easier to remove the build files.
> > FYI what we do in release scripts, is to do a local clone to a different
> > directory [2]:
> > git clone ltp ltp-full-YYYYMMDD

> > Not sure what is faster.

> I guess that is something a script could also do then 'git clean'
> becomes a null op. git clean -X will only remove untracked files so
> pending changes should get picked up. Which is probably what people want
"remove untracked files" - if you develop a new test, forget to add it with 'git
add' and run the container, you will get disappointed :).

> during development. Doing a fresh checkout is probably more like a hard
> reset and clean.

The benefit is that you have not only a clean git repo for the container,
but also not touching your working copy directory. But unless nobody else
raise any concern, I'm ok with your current proposal.

> AFAICT git clean is very quick, far faster than 'make distclean'.


> >>     * Added seperate alpine and tumbleweed runtime scripts. Again it's
> >>       different from the suggestion just because it's easier to add
> >>       seperate scripts than adding a switch
> > +1

> > But maybe put it into container directory, because it's not used in
> > GitHub CI?

> I was thinking it could be used in CI. All we need is a CI that runs VMs
> and we can do some testing. (e.g. srchut).

Makes sense. Also, having scripts on two directories can lead to confusion,
let's keep it in ci directory.

...
> >> +#!/bin/sh -eux
> > nit: out of curiosity, why -u (fail unset variables and parameters)?

> I find it finds errors in shell scripts or when using them. E.g. typo's
> in env variable names. I just include it wherever possible.

+1, maybe we should add it to the current ci scripts as well (+ use params
instead of setting it via set command, it should work in dash and busybox shell
as well).

Kind regards,
Petr

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

  reply	other threads:[~2023-09-29  8:15 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-28 10:44 [LTP] [PATCH] Add simple Containerfile Richard Palethorpe via ltp
2023-09-28 18:11 ` Petr Vorel
2023-09-29  7:42   ` Richard Palethorpe
2023-09-29  8:15     ` Petr Vorel [this message]
2023-09-29  9:15       ` Richard Palethorpe
2023-09-29  9:37         ` Petr Vorel
2023-10-04 12:28 ` Marius Kittler
2023-10-05  8:07   ` Richard Palethorpe
2023-10-10 11:28 ` Andrea Cervesato via ltp

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=20230929081521.GA351787@pevik \
    --to=pvorel@suse.cz \
    --cc=ltp@lists.linux.it \
    --cc=rpalethorpe@suse.de \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.