[Toybox] GitHub Action Example

Sun Jun 28 23:35:33 PDT 2020

So many open old email windows...

On 6/19/20 7:23 PM, enh wrote:
> On Wed, Jun 17, 2020 at 1:46 PM Rob Landley <rob at landley.net> wrote:
>>
>> On 6/16/20 3:27 PM, enh wrote:
>>> On Mon, Jun 15, 2020 at 4:05 PM Rob Landley <rob at landley.net> wrote:
>>>>
>>>> On 6/15/20 1:42 PM, enh wrote:
>>>>> On Mon, Jun 15, 2020 at 11:05 AM Rob Landley <rob at landley.net> wrote:
>>>>>>> i don't actually remember us ever having an aarch64-specific issue.
>>>>>>> (funnily enough, a 32-bit x86 build would probably find more bugs,
>>>>>>> since i don't think anyone regularly tests any 32-bit arch locally. i
>>>>>>> certainly only find 32-bit issues when i try to run on an Android
>>>>>>> emulator!)
>>>>>>
>>>>>> I test it before releases, and I test the j-core stuff which is still only 32
>>>>>> bit. But it's not tested nearly as regularly as the 64 bit stuff is.
>>>>>
>>>>> (to be clear, i meant "at the time of commit". thanks to the 32-bit
>>>>> x86 "cuttlefish" emulator testing, we do get testing every time i try
>>>>> to sync AOSP. but .)
>>>>
>>>> This wouldn't be at time of commit either, this would be at time of push to
>>>> github. Which lately has been a day or so after my local commit on my laptop
>>>> because I forget. :P
>>>
>>> as far as the other ~8 billion people on the planet are concerned,
>>> that's the same thing :-)
>>
>> Yes, but 99.99% of them get it through you, then a phone manufacturer, than a
>> telecom vendor on a collective 18 month delay, and very few of them are the ones
>> who have to root cause the issue and come up with a patch.
> 
> yeah, okay, you got me: mainly this would benefit me :-)
>
> (i am volunteering to keep the mac build green though!)

I applied the commit and sent you an invite.

>> I admit this is probably a thing I should do, if for no other reason than I
>> haven't got macos test hardware. (Unfortunately, the mac version of a raspberry
>> pi appears to be $800: https://www.apple.com/shop/buy-mac/mac-mini .)
> 
> and even though i have a MBP available, it's sufficiently awful that i
> only try it if i know there's a problem. and our automated Mac build
> infrastructure is running on "Apple Pi"s too, so sucks. we find out
> days later.

If darwin ever turns into a real thing I can run under macos in a way that
matters and actually compile and test stuff, then I start to care. But
https://opensource.apple.com/darwinsource went from "not booting under qemu" to
a 404 error.

>> But if it DID work then presumably I'd adb shell into it somehow and work out
>> how to run the test in there?
> 
> afaik, if you're not on the emulator team, you need to use a prebuilt.
> it's broken more than it works.

Sigh.

> i'd recommend cuttlefish
> (https://source.android.com/setup/create/cuttlefish) instead. that's
> what we use for our large scale testing. it's been a lifesaver while
> WFH --- if you brick a real device, you probably can't get it into the
> bootloader remotely!

Yay cuttlefish.

> seems like for real people their suggestion is basically "download an
> image we built earlier"
> (https://android.googlesource.com/device/google/cuttlefish/). which is
> effectively what i do on a daily basis, just less automated.

This is why the phrase "continuous integration" makes me break out in a rash.

I've seen builds that only reproduce properly on Magic Build Machine, projects
where regressions are common enough they only have a good build every every once
in a while and don't bother to tag which ones those are, and the ever-popular
builds with all the dependencies in the world each of which is a dynamically
updated tip-of-tree du jour package and on average at least one of them is
broken at any given time but the stars align every once in a while and you get a
good build you can then never reproduce (and need weeks of feature freeze to get
a release candidate out).

I may have done rather a lot of consulting at Fortune 500 companies over the
years...

>>> yeah, for my money the "we'll check you can still build on macos"
>>> alone is worth it, macos being such a pain in the ass to deal with
>>> otherwise.

As far as I'm concerned this is the reason to use that plumbing. I can set up an
ubuntu kvm image easily enough if that turns out to be relevant, but there's
been a lot of "reproduce this one bug under pclinuxos" and "gentoo did something
strange with" that I've set up an image for, debugged, and then never used that
image again. (*shrug* still worth doing, but I wait for the specific bug report
from the person who hit it.)

>> Indeed, but that provides regression testing without a development environment.
>> If it finds a bug on macos, what do I _do_ about it?
> 
> assuming i can't subscribe to these (and i'm assuming i _can_), let me
> know. it's always better to know about these things when there isn't a
> fire drill going on.

Indeed.

>> (I still have a todo item to dig into that ps library and try to do a
>> portability.c to fill out at least _some_ of the ps fields, and I can come up
>> with a freebsd test for that, and in THEORY going from freebsd to macos is like
>> going from devuan to RHEL. Plenty of breakage but at least related species, and
>> I've had bsd development environments running under kvm before, and can maybe
>> poke Ed Maste to help there if I set aside time to work on it... :)
> 
> no, as far as i could from looking into this they're all significantly
> different. you'll need to do it N times. (which is why i've _not_
> volunteered for that. definitely don't care about the Mac that much!)

I care about freebsd, but it has a linux binary emulation layer, and digging
into their magic library they were patching together multiple different ways to
query information and sticking it into a structure. 80% of what Linux is doing
is providing an array of numbers in /proc/$PID/stat. (That said, querying the
other 20% on Linux SUCKS.)

There should be a standardized api for this stuff, and there are reasons Plan 9
didn't take over the world. If https://lwn.net/Articles/650243/ ever resurfaces
I'm happy to support it. The lack of this was one of the big failures in the
original unix design (I vaguely recall that the unix v6 way was "traverse kernel
structures in /dev/mem without obvious locking").

But I can't invent an API to use.

>> I should look at android go. Is that one of the "lunch" targets? (Unfortunately
>> googling for "android lunch go" hits the fact you named a programming language
>> go and wrote half your build system in it.)
> 
> in our circles, that's "golang". "go" is
> https://www.android.com/versions/go-edition/.

It still screws up the search results.

> afaik there's no AOSP lunch target for it. vendor blobs :-(

Half my problem with AOSP is I don't know what my _options_ are. It's Giant Pile
of Everything.

  https://www.youtube.com/watch?v=CXrFFWmbacI

>> Ahem. Computer history hobby = I researched how this sausage was made at some
>> length.
> 
> aye, but if it goes away, the worst that happens is we need to find
> another way to do CI. and as the other guy on the thread said: in the
> meantime, if nothing else you can feel good about eating their CPU
> cycles :-)

I've seen too many frogs boiled, as it were. (I'm told actual frogs will jump
out of the pot as the temperature rises, because frogs are smarter than humans.)

Since microsoft changed CEOs I've gone from:

  https://www.youtube.com/watch?v=aCbfMkh940Q
  https://www.youtube.com/watch?v=6DGNZnfKYnU

To more of a mitchell and webb "contractor for supervillains, health and safety
edition" approach:

  https://www.youtube.com/watch?v=VgX6JFoV0TM#t=1m55s

[long section about setting up a branch to have the .git build stuff in deleted,
since I suppressed my gag reflex long enough to commit it to mainline anyway.]

Rob