Craig,
I think you are confusing my confusion ;-)
My point is, we're not going to invest in #2 on Ubuntu. Sure, we could. Not gonna do it, unless it puts RHEL where I want it to be. Why on Earth would we spend engineering resources to enable Ubuntu runners on GitHub Actions?
And, yes right after I fired off the email, I realized these were implemented by Docker, not GitHub (the company). I view this as a two part Feature:
1. Make RHEL available as a runner at GitHub. This would justify investment in building #2
2. Create GitHub actions code for automation, which would live in the containers (aka Podman) community
3. Perhaps productize these as some sort of RHEL/UBI content which people could depend on Red Hat for. AKA, a productized version of #2.
But, getting #1 done first is key, because our goals as a company are not to use Podman engineers to enable Ubuntu in a key place where developer eyeballs and fingers are working. This is essentially free marketing which we should not leave on the table. Also, this ties into a much bigger, strategic initiative that I have as the RHEL Server product manager - make RHEL available everywhere (GitHub Actions, make it work in GitLab (still working on that), make UBI an Official Image on DockerHub, build out Podman Desktop for Mac/Windows, enable RHEL in WSL2. There's a common theme to all of these. Availability of RHEL.
In marketing there's the concept of zero, first, second, and third moments of truth. I won't bore you with all of the details, but we're failing (worst) at the first moment of truth. The customer goes into the frozen pizza aisle and there's no Red Baron pizza to even buy. In this case, it's no RHEL available at GitHub Actions (as well as Digital Ocean, Linode, CircleCI, CirrusCI, Windows Store for WSL2, etc). We need the Red Baron pizza in the frozen foods section at all grocery stores.
Then, it's worth building out automation to drive consumption.
Best Regards
Scott M
