[Toybox] Horrible microsoft github tests spamming me.

[enh]

On Sun, Aug 9, 2020 at 7:00 AM Eric Molitor <emolitor at molitor.org> wrote:

> Make sure you are logged into github and go to
> https://github.com/settings/notifications near the middle of that page
> you will find the notification settings for GitHub actions allowing you to
> disable and configure them as necessary.
>
> For Rob, you probably want to uncheck all the github action notifications
> so they never bother you again.
> For Elliot, spam yourself silly.
>
> Furthermore, at the bottom of the page you should see a "Custom Routing"
> section that you can customize which projects go to which email addresses.
>

huh. annoyingly, i only seem to have android, android-ndk, and google
listed there.

(if i click on "things you're watching", toybox is in *that* list, but the
"change notification settings" on that page just takes me back to where i
came from :-( )


> - Eric
>
> On Wed, Aug 5, 2020 at 4:46 PM enh via Toybox <toybox at lists.landley.net>
> wrote:
>
>> On Tue, Aug 4, 2020 at 8:40 PM Rob Landley <rob at landley.net> wrote:
>> >
>> >
>> >
>> > On 8/4/20 10:38 AM, enh wrote:
>> > > On Mon, Aug 3, 2020 at 11:41 PM Rob Landley <rob at landley.net> wrote:
>> > >>
>> > >> I got email about https://github.com/landley/toybox/runs/940149373
>> in which one
>> > >> of the cpio tests spuriously failed. I cannot cut and paste the
>> failure because
>> > >> microsoft github's crammed so much javascript into the reporting
>> page that
>> > >> doesn't work.
>> > >>
>> > >> The last time cpio.c changed was april, the last time
>> tests/cpio.test changed
>> > >> was may, and the last time lib/* or any of the scripts/test plumbing
>> changed was
>> > >> June.
>> > >>
>> > >> The test failed for non-obvious reasons which look like a shell race
>> condition
>> > >> with | or something? The test is doing a dd to grab a specific byte
>> offset out
>> > >> of the file. and the chunk it's looking at starts 8 bytes too early
>> to get a
>> > >> match with what it expects. Is this a dd problem? Is the file longer
>> with
>> > >> spurious crap inserted earlier in it? Did the container's | insert
>> extra data?
>> > >> Who knows, I haven't a clue how to dig any of the build artifacts
>> out of this
>> > >> mess, but I got email about it.
>> > >
>> > > yeah, this is where i've been for years with the "found by Android CI"
>> > > bugs. one thing i can say is that i'm _not_ seeing this on Android's
>> > > CI. (an obvious difference there is that we use toybox dd!)
>> >
>> > I tend to have thing | thing rather than checkpointing temporary files
>> so I
>> > don't have to clean up the temp files. What I really need to do is make
>> the test
>> > self-cleaning between invocations (which means run test rather than
>> source test,
>> > which means export variables that need exporting, which isn't a big
>> deal it's
>> > just a todo item a bit down on the list)...
>> >
>> > But "thing > file && thing < file" does let you examine the
>> intermediate parts
>> > after a failure better. I just don't assume suprious failures on the
>> part of
>> > _my_ infrastructure (outside of pending). I do, sadly, assume spurious
>> failures
>> > on the part of ubuntu crap because I've hit several over the years (and
>> reported
>> > some upstream). The entire constellation of SA_RESTART issues where
>> SIGSTOP and
>> > friends cause short reads on pipes, for example, and a zero length read
>> is NOT
>> > necessarily EOF... I try to get that stuff right, and when there's a
>> suprious
>> > only-happened-once thing like this I'll examine the code to see if I
>> can figure
>> > out how it happened...
>> >
>> > But this isn't my code, this is ubuntu's shell and ubuntu's dd testing
>> in
>> > microsoft github's container, and like 80% of the exposed surface area
>> here
>> > isn't my stuff, which makes the likelihood of finding the bug is 20%...
>> >
>> > > anyway, the first time i see a failure i just take a mental note to
>> > > prime myself for future occurrences and assume cosmic ray/failing
>> > > hardware/bad kernel unless i see it again.
>> >
>> > If it happens on my laptop I will drop EVERYTHING and reproduce/explain
>> it.
>> > Which sometimes takes days. It's one of those "I dropped a glass,
>> there's
>> > fragments everywhere, DO NOT MOVE, DO NOT STEP ON ANYTHING" situations.
>> >
>> > If it happens in a random vm like this? 4 times out of 5 it's the VM.
>>
>> (on Android, 4 times out of 5 i accuse it of being x86 vs arm, and 4
>> times out of 5 it's actually 32-bit vs 64-bit :-) )
>>
>> > > the nice thing about CI though is that it doesn't take long before
>> > > it's run the tests more often than all the humans put together.
>> >
>> > Oh sure. I seriously want to expand test coverage, but it's far down
>> the todo list.
>> >
>> > >> I thought I was not going to get these emails, and am sad. And to
>> add insult,
>> > >> the github email says it's from "Rob Landley", which is very much
>> not the case.
>> > >
>> > > annoyingly, i _want_ to get them, but don't. (and don't know how to
>> > > sign up for them either :-( )
>> >
>> > You should have access to fiddle. I dunno how github works under the
>> surface...
>>
>> yeah, i was assuming you wouldn't know either --- i was hoping Eric
>> would point us in the right direction again :-) (i did at least manage
>> to follow his directions to get the full log without it being
>> bizarrely restricted to a tiny scrolling area on my huge screen!)
>>
>> > Rob
>> _______________________________________________
>> Toybox mailing list
>> Toybox at lists.landley.net
>> http://lists.landley.net/listinfo.cgi/toybox-landley.net
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.landley.net/pipermail/toybox-landley.net/attachments/20200811/12d4b6f2/attachment-0001.htm>