All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH] autobuild-run: add --repo option
Date: Tue, 18 Jul 2017 10:19:48 +0200	[thread overview]
Message-ID: <20170718101948.2d81c105@windsurf> (raw)
In-Reply-To: <d958d5e4-3a8e-886d-5cc0-b632b15bd748@mind.be>

Hello,

On Tue, 18 Jul 2017 10:12:11 +0200, Arnout Vandecappelle wrote:

> > Would it be reasonable to request that if a custom repo is used, then
> > uploading the results to autobuild.b.o is not possible ?  
> 
>  But Matt's use case is exactly that he doesn't have a good connection to the
> upstream repo so he wants to use a mirror, but still upload to a.b.o.
> 
>  Admittedly, this is exactly what lead to the recent problems with Matt's
> autobuilder...

Exactly my point: Matt's experience has shown that using a non-default
repository was causing problems, hence my resistance to this change.

In addition, if one is not able to fetch from https://github.com in a
reliable way, I don't see how one can decently run an autobuilder
instance that will anyway require download tons of stuff from various
places on the Internet.

> > Or am I too zealous about this ?  
> 
>  Yes you are. Without this change, someone like Matt will just edit the
> autobuild-run script and you still have the same problem :-)
> 
>  Perhaps we can make the problem at least detectable, by pushing *kwargs to
> a.b.o in addition to the BR git ID. But that obviously requires modifications on
> a.b.o itself, which is a bit more difficult to organize I guess.
> 
>  Since you're the BDFL for autobuild-run, feel free to follow up this patch with
> something that disables uploading if --repo is non-default. And let Matt solve
> his own problems :-)

Or I could add a server-side check that the git commit being reported
exists in the upstream Buildroot, and is not more than 1 or 2 days old.
It probably makes more sense to do this server-side. Which means I
could merge your --repo option (even if I still find its use cases
very, very dubious).

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

  reply	other threads:[~2017-07-18  8:19 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-17 21:28 [Buildroot] [PATCH] autobuild-run: add --repo option Arnout Vandecappelle
2017-07-18  2:45 ` Matthew Weber
2017-07-18  7:24   ` Arnout Vandecappelle
2017-07-18  7:57 ` Thomas Petazzoni
2017-07-18  8:12   ` Arnout Vandecappelle
2017-07-18  8:19     ` Thomas Petazzoni [this message]
2017-07-18  8:25       ` Arnout Vandecappelle
2017-07-18 11:46         ` Matthew Weber
2017-07-25 20:24 ` Thomas Petazzoni

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=20170718101948.2d81c105@windsurf \
    --to=thomas.petazzoni@free-electrons.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 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.