ttshivers

> > One possibility is to change the update.sh to generate a single action file that has one big matrix like: > > I originally split them over to separate...

> You could also consider using Travis just for multi-arch testing (https://docs.travis-ci.com/user/multi-cpu-architectures/), which would allow the builds to be native instead of emulated. Natively building would certainly be much faster....

> Both those arm32 arches can build on the graviton instances, and i386 can build on any amd64. Ah ok. That's certainly a valid option then. One note is that...

> Now that the generated build matrix landed, does this get easier? Yeah. I think it will be significantly simplified. Also, the logic I've done in https://github.com/nodejs/docker-node/pull/1341 will help with...

> Ah, I guess the initial one is going to create a diff no matter what since it also fixes the sorting of the image names. > > ```diff >...

> Overall I like this. Probably need to figure out how to things might be filtered. EX: no support on 386 Linux or maybe armv5/mips Yeah, that is the one...

One reference for supported platforms is: https://github.com/nodejs/node/blob/master/BUILDING.md#platform-list

> Using the Tier 1/Tier 2/Experimental on the multi-arch setup would be an interesting approach. Could mark the Tier 1 and maybe Tier 2 as required passing checks, but allow...

How should we store those tiers? In a json file somewhere or some other format?

Sure. I can start off with the md files. Unsure about whether the Dockerfile lint errors should be fixed.