On Fri, Jul 12, 2024 at 12:33 PM brian m. carlson <sandals@xxxxxxxxxxxxxxxxxxxx> wrote: > > On 2024-07-11 at 23:15:35, Emily Shaffer wrote: > > On Thu, Jul 11, 2024 at 3:24 PM brian m. carlson > > <sandals@xxxxxxxxxxxxxxxxxxxx> wrote: > > > Some older OSes require kernel features that aren't compiled in by > > > default, so containers are out. For example, CentOS 6 won't run on a > > > modern kernel because it lacks whatever the predecessor to the vDSO was > > > (which can be recompiled into the kernel, but nobody does that). > > > > Is this hinting that we should mention a minimum kernel version for > > Linux-kernel-based OSes? > > This is actually a feature that still exists in the kernel and could be > enabled for newer kernels, but because distros don't use it (they use > the vDSO instead), they don't compile it in. > > I'm not sure a minimum kernel version is helpful, because most of the > LTS distro kernels backport features, like Red Hat backported getrandom > for example. In the interests of getting to a useful agreement, I think > for now we should just punt on this and having a 10 year lifespan will > probably do the trick, and we can determine in the future if we need to > apply more stringent measures. Sounds good, thanks! > > > > We also don't really want to be on the hook for trying to support OSes > > > Ubuntu is still derived from Debian. It is likely that things which > > > work in one will work in another, but not guaranteed. > > > > > > I mention Debian is because it has a large variety of supported > > > architectures. I absolutely don't want to say, "Oh, you have MIPS > > > hardware, too bad if Git doesn't work for you." (I assure you the > > > distro maintainers will be displeased if we break Git on less common > > > architectures, as will I.) In fact, MIPS is an architecture that > > > requires natural alignment and can be big-endian, so it's very useful in > > > helping us find places we wrote invalid or unportable C. > > > > > > The reason I'm very hesitant to require that we run everything in GitHub > > > Actions because it only supports two architectures. ARM64 and RISC-V > > > are really popular, and I can tell you that running even a Linux > > > container in emulation is really quite slow. I do it for my projects, > > > but Git LFS only builds one set of non-x86 packages (the latest Debian) > > > because emulation is far too slow to build the normal suite of five or > > > six packages. > > > > Does that restriction apply to just GitHub-hosted runners, though? > > Would it be possible for an interested party to set up self-hosted > > runners (configured via GH Actions) that are using AMD or POWER or > > whatever? (For example, I think it would be quite feasible for Google > > to donate some compute for this, though no promises). > > Self-hosted runners on public code are very hard to secure. You're > basically letting arbitrary people on the Internet run code on those > machines and make outgoing network connections (due to the fact that you > can push whatever into a PR branch), with all of the potential for abuse > that that involves (and as my colleagues can tell you, there's a whole > lot of it). GitHub has taken extensive pains to secure GitHub Actions > runners in the cloud, and while we use self-hosted runners for some > internal projects, they are absolutely not allowed for any public > project for that reason. > > I would be delighted if Google were willing to do that, but I think > you're going to need help from teams like Google Cloud who are going to > be used to dealing with abuse at scale, like cryptocurrency miners and > such. Unfortunately, there are many people who act in a less than > lovely way and will exploit whatever they can to make a buck. > > I will also note that the official Actions runner is in C# and only runs > on a handful of platforms due to the lack of portability of C#. (It > might theoretically run on Mono, which would increase its portability, > but I must profess my complete ignorance on anything about that code.) I > also know of an unofficial one in Go[0], which I'm for obvious reasons > unable to endorse, encourage, or speak about authoritatively in any way, > but that would still exclude some platforms and architectures which > don't support Go. Do you think it's worth us linking out to some helpful doc (like the official one, and someone who doesn't work at GH adding a link to some unofficial Golang thing)? I sort of feel like since "you can also DIY a scraper that looks at the mailing list if you want" is included, the gist makes it across, so I'm tempted not to go into a bunch of prescriptive detail here. > > > The appeal is not "because GitHub Actions are great!" for me - the > > appeal is "because most Git developers run the CI this way if they > > remember to or use GGG, and Junio runs it on `seen` all the time". If > > there's some other recommendation for self-service CI runs that don't > > need some careful reminding or secret knowledge to run, I'm happy with > > that too. (For example, if someone wants to set up some bot that looks > > for new [PATCH]-shaped emails, applies, builds, runs tests, and mails > > test results to the author after run, that would fit into the spirit > > of this point, although that sounds like a lot of setup to me.) > > Yeah, I understand what you're going for. If there were some super easy > way to get everything running in an automatic CI, I'm all for it. I > think CI is the easiest way to make sure we don't break anything. > > I think it's worth trying to get CI set up for whatever we can, and if > CI is a possibility somewhere, it becomes a lot easier to say yes. > > > Should have a reroll in the next 30min, it was ready to go and then I > > got this mail :) > > Sounds good. I don't think anything in this email should affect that > reroll. > > [0] https://github.com/ChristopherHX/github-act-runner > -- > brian m. carlson (they/them or he/him) > Toronto, Ontario, CA
