All of lore.kernel.org
 help / color / mirror / Atom feed
From: Martin Jansa <martin.jansa@gmail.com>
To: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Cc: OE Core mailing list <openembedded-core@lists.openembedded.org>
Subject: Re: [PATCH 0/2] Avoid build failures due to setscene errors
Date: Fri, 29 Nov 2019 17:48:50 +0100	[thread overview]
Message-ID: <CA+chaQdRJQ8i+a2Ko3_D7Gp=yAJvA5M5wCmZstMykip-x-FYbg@mail.gmail.com> (raw)
In-Reply-To: <CA+chaQeak4gD3C=jgxE-gg=9yf+g=4sgcHqP3ooMVRMJsbtO5w@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2625 bytes --]

On Wed, Aug 30, 2017 at 9:54 AM Martin Jansa <martin.jansa@gmail.com> wrote:

> I agree with this patchset and it would be OK with IGNORE_SETSCENE_ERRORS
> conditional as well.
>
> We're also sometimes seeing these errors, sometime anticipated when
> cleaning shared sstate-cache on NFS server sometimes unexpected when NFS or
> network goes down for a minute and for some builds it happens between
> sstate_checkhashes()  and using the sstate.
>
> We normally stop all jenkins builds, until the cleanup is complete (there
> is jenkins job doing the cleanup, so it puts jenkins into stop mode, waits
> for all current jobs to finish which can take hours, then performs the
> cleanup and cancels the stop mode), but we cannot stop hundreds of
> developers using the same sstate-cache in local builds (especially when we
> cannot really know when exactly the job will have free jenkins to perform
> the cleanup) - luckily in local builds it doesn't hurt so bad, because the
> developers are more likely to ignore the error as long as the image was
> created, but in jenkins builds when bitbake returns error we cannot easily
> distinguish this case of "RP is intentionally warning us that something
> went wrong with sstate, but everything was built correctly in the end" and
> "something failed in the build and we weren't able to recover from that,
> maybe even the image wasn't created" - so we don't trigger the follow up
> actions like announcing new official builds or parsing release notes or
> automated testing.
>
> Yes we could add more logic to these CI jobs, to grep the logs to decide
> if this error was the only one which caused the bitbake to return error
> code and ignore the returned error in such case, but simple variable is
> easier to maintain (even for the cost of forking bitbake and oe-core) and
> will work for local builds as well.
>

 I was using these 2 changes in my fork of oe-core and bitbake since they
were sent to the list, but today after getting a bunch of errors like this
from build which unfortunately wasn't using my forks and few questions
about why these errors aren't ignored from fellow developers I've finally
found time to improve our CI jobs to deal with this and ignore the bitbake
return code if it's reporting failure only because of these setscene
fetcher failures.

If someone needs similar work around for bitbake behavior, here is what I
did:
https://github.com/webOS-ports/jenkins-jobs/pull/12
yes, it's ugly, but it seems to work and is a bit better than forking
oe-core and bitbake just because of this issue.

Regards,

[-- Attachment #2: Type: text/html, Size: 3479 bytes --]

  reply	other threads:[~2019-11-29 16:49 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-29 20:00 [PATCH 0/2] Avoid build failures due to setscene errors Peter Kjellerstedt
2017-08-29 20:00 ` [PATCH 1/2] bitbake: fetch2: Allow Fetch.download() to warn instead of error Peter Kjellerstedt
2017-08-29 20:00 ` [PATCH 2/2] sstate.bbclass: Do not cause build failures due to setscene errors Peter Kjellerstedt
2017-08-29 20:04 ` ✗ patchtest: failure for Avoid " Patchwork
2017-08-29 20:25   ` Peter Kjellerstedt
2017-08-29 22:35     ` Philip Balister
2017-08-30  7:41       ` Peter Kjellerstedt
2017-08-29 20:38 ` [PATCH 0/2] " Andre McCurdy
2017-08-29 20:59   ` Peter Kjellerstedt
2017-08-29 21:49     ` Richard Purdie
2017-08-30  6:44       ` Peter Kjellerstedt
2017-08-30  7:54         ` Martin Jansa
2019-11-29 16:48           ` Martin Jansa [this message]
2020-01-09 12:26             ` Ricardo Ribalda Delgado
2017-08-30  8:02         ` Richard Purdie
2017-08-30  9:52           ` Peter Kjellerstedt
2017-08-29 22:03     ` Andre McCurdy
2017-08-30  9:55       ` Peter Kjellerstedt

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='CA+chaQdRJQ8i+a2Ko3_D7Gp=yAJvA5M5wCmZstMykip-x-FYbg@mail.gmail.com' \
    --to=martin.jansa@gmail.com \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=peter.kjellerstedt@axis.com \
    /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.