Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Yann E. MORIN <yann.morin.1998@free.fr>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH] support/misc/gitlab-ci.yml.in: include Branches workflow
Date: Mon, 31 Aug 2020 21:52:01 +0200	[thread overview]
Message-ID: <20200831195201.GR14354@scaer> (raw)
In-Reply-To: <2388ea60-a8cb-9685-b075-11b1a49be9ff@mind.be>

Arnout, All,

On 2020-08-31 14:58 +0200, Arnout Vandecappelle spake thusly:
>  Note that it's not the complicated conditions on the defconfig and test jobs
> that are the issue. The warning is also issued for check-flake8... So I think
> the workflow will still be needed (or alternatively, every job should have a
> condition to run only on branches).

Sorry, but I don't follow: if the jobs are only generated when we want
them, then they no longer have conditions in the generated gitlab-ci.yml
to begin with; that's the whole point of moving the conditional handling
into the script.

> On 31/08/2020 14:43, Yann E. MORIN wrote:
> > I'd like to suggest an alternative: move all the conditions into the
> > generating script, now that we do have a script that generates the
> > pipeline description.
[--SNIP--]
>  Also, I would like to move the "constant" bits back out to the top-level
> gitlab-ci.yml, so the first page already shows the quick test results.

Sorry, but again they are not "constant". For example, check-flake8,
check-package and check-DEVELOPERS are not run when one pushes a
*_defconfig or *_test branch (or however they are named) to trigger the
build of jsut that defconfig or just that runtime test.

> > Having the conditions in the script will help handle such cases, by only
> > ever emitting those jobs we actually want to run. This would allow for
> > more flexibility than the limited micro-language used by gitlab-ci.yml.
> > 
> > Also, this will allow us to not care about the evolutions of that micro-
> > language.
>  I think that's a great idea. However, that sounds like a bigger change which
> probably shouldn't go into master. So I'd prefer to still merge my patch as well.

See an actual comment on that patch, below...

> >> diff --git a/support/misc/gitlab-ci.yml.in b/support/misc/gitlab-ci.yml.in
> >> index dddebf09e9..8a031898ef 100644
> >> --- a/support/misc/gitlab-ci.yml.in
> >> +++ b/support/misc/gitlab-ci.yml.in
> >> @@ -1,6 +1,9 @@
> >>  # Configuration for Gitlab-CI.
> >>  # Builds appear on https://gitlab.com/buildroot.org/buildroot/pipelines
> >>  
> >> +include:
> >> +  - template: 'Workflows/Branch-Pipelines.gitlab-ci.yml'

Where does that file come from? How are we guaranteed that its content
does not change and break our pipelines?

If that template is interesting, then we should carry it rather than
depend on an external, un-managed entity...

Regards,
Yann E. MORIN.

> >>  image: buildroot/base:20200814.2228
> >>  
> >>  .check_base:
> >> -- 
> >> 2.26.2
> >>
> >> _______________________________________________
> >> buildroot mailing list
> >> buildroot at busybox.net
> >> http://lists.busybox.net/mailman/listinfo/buildroot
> > 

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 561 099 427 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

  reply	other threads:[~2020-08-31 19:52 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-30 15:59 [Buildroot] [PATCH] support/misc/gitlab-ci.yml.in: include Branches workflow Arnout Vandecappelle
2020-08-31 12:43 ` Yann E. MORIN
2020-08-31 12:58   ` Arnout Vandecappelle
2020-08-31 19:52     ` Yann E. MORIN [this message]
2020-09-01  6:52       ` Arnout Vandecappelle
2020-08-31 21:49     ` Yann E. MORIN
2020-10-06 20:42 ` 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=20200831195201.GR14354@scaer \
    --to=yann.morin.1998@free.fr \
    --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