From: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH] infra: add the transient download mechanism
Date: Thu, 16 Jan 2020 10:31:20 +0100 [thread overview]
Message-ID: <20200116103120.7b41295a@windsurf> (raw)
In-Reply-To: <534f269547ead6d86e7a571978b54d79cd24cd0d.camel@orolia.com>
Hello,
On Thu, 16 Jan 2020 09:11:32 +0000
Nicolas Carrier <nicolas.carrier@orolia.com> wrote:
> One small remark, to be able to reproduce the build, on top of this
> mechanism, there should be:
> * a way to store the actual VCS revision used for the build (to at
> least know what was just built!)
That seems quite easy to do.
> * a way to force the build to re-use a particular set of revisions
I don't see how that can be done however, and how that would work from
a user interface point of view. Sure the first build could store the
exact Git commit used for building each transient package, and store
that "somewhere", and then re-use that for the next build. But how does
the user decide whether what he wants is to re-do the build with the
same commits or not ? Where is that "somewhere" ?
> That's part of why I don't think that this kind of feature is a good
> thing to integrate into buildroot. I prefer to delegate it to tools
> meant for that (using a mix of local packages and OVERRIDE).
Different people/companies have different work flows. We have people
telling us that using local packages and OVERRIDE for their CI is not
very convenient/practical.
> And like said before, I think it's preferable to have a optional
> feature to prevent branches from being used, making the build fail.
The feature proposed by Yann *is* optional, as it's conditional on
having a specific variable set in the package .mk file.
However, one question that is raised by Yann's patch is whether we want
to forbid using branches when TRANSIENT_DOWNLOAD is NO.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
next prev parent reply other threads:[~2020-01-16 9:31 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-15 20:37 [Buildroot] [PATCH] infra: add the transient download mechanism Yann E. MORIN
2020-01-15 22:04 ` Michael Nazzareno Trimarchi
2020-01-16 22:36 ` Arnout Vandecappelle
2020-01-16 9:11 ` Nicolas Carrier
2020-01-16 9:31 ` Thomas Petazzoni [this message]
2020-01-16 9:56 ` Michael Nazzareno Trimarchi
2020-01-16 10:03 ` Thomas Petazzoni
2020-01-16 10:15 ` Michael Nazzareno Trimarchi
2020-01-16 15:35 ` Yann E. MORIN
2020-01-16 16:52 ` Michael Nazzareno Trimarchi
2020-01-16 10:01 ` Nicolas Carrier
2020-01-16 10:05 ` Thomas Petazzoni
2020-01-16 15:45 ` Yann E. MORIN
2020-01-16 15:29 ` Yann E. MORIN
2020-01-16 22:49 ` Arnout Vandecappelle
2020-04-08 6:39 ` Thomas Petazzoni
2020-04-08 19:27 ` Yann E. MORIN
2020-04-08 20:03 ` Thomas Petazzoni
-- strict thread matches above, loose matches on Subject: below --
2020-04-27 20:04 Yann E. MORIN
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=20200116103120.7b41295a@windsurf \
--to=thomas.petazzoni@bootlin.com \
--cc=buildroot@busybox.net \
/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