Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Linux distribution available as virtual environments for GitHub Actions ( or rather lack there of ) #45

Closed
johannbg opened this issue Oct 17, 2019 · 15 comments

Comments

@johannbg
Copy link

Describe the bug

When providing integrated linux distribution support, be it for devices, tools, build system, projects, for package management system/support in distributions there are 5 parent distribution and their package management system that should be supported always since by doing so you will cover the more or less the rest of what the 400 - 500 Linux distributions out there which are deviating from their parent distribution ( which more or less are those fives ) based on religions purposes or disagreement ( fork offs ) not from technical or development standpoint, causing needless deviation and pain points for upstream developers and system administrators in the core/baseOS stack, in which upstreams ( company's and opensource developers ) build their application stack upon and developers and system administrators have to deploy and support.

Arch ( derivative for example Manjaro )
Debian ( derivative for example Ubuntu )
Fedora ( derivative for example Redhat/CentOS )
Gentoo ( derivative for example Google's ChromeOS )
OpenSuse ( derivative for example SUSE Linux Enterprise/SLES )

Virtual environments affected
The virtual environments provider itself.

Expected behavior
Expected behaviour is to be able to chose one of the 5 parent distributions as a supported virtual environments and hardware resources as I previously mentioned before and those distribution being outlined and mentioned here [1] and here [2] as an available OS options for "runs-on:" or atleast the "Guest operating systems supported on Azure Stack" as outlined here [3] in Azures documentations so distributions that would like to be supported as Linux distribution available as virtual environments for GitHub Actions, would then have to work towards getting themselves officially supported as an guest operating system on Microsoft's Azure Stack.

Actual behavior
Only Ubuntu listed as an option which is an Linux distribution that only works by hack-ish workarounds rather than solving real fundamental OS/Desktop issues and seem to attract more often than not some hipster programming diva's who spend more time on starbucks coffee shops at their employees expense rather than developing software or solve real problems in the software universe.

A better alternative would be providing Debian as the singular linux run-os option.

Another thing worth mentioning is that there seems to be no documentation why Github has chosen to chose Ubuntu as the only linux distribution of chose. Did Canonical/Mark Shuttleworth specifically pay Github for that Linux monopoly which then should be mentioned somewhere...

  1. https://help.github.com/en/articles/virtual-environments-for-github-actions
  2. https://help.github.com/en/articles/software-in-virtual-environments-for-github-actions
  3. https://docs.microsoft.com/en-us/azure-stack/operator/azure-stack-supported-os?view=azs-1908
@ADmad
Copy link

ADmad commented Oct 17, 2019

If you don't like Ubuntu can't you just use a docker image based on distro of your choice?

Other CI / CD providers like TravisCI, CircleCI also use Ubuntu for their Linux VMs, so surely the "hack-ish workarounds" you claim Ubuntu needs isn't an issue for most.

@oldskool
Copy link

That's a lot of Ubuntu hate there and insulting a lot of people that use it in the process. Was that really necessary? I guess you needed to let go of some built up frustration. 😕

Anyway, yes, Ubuntu is currently the only choice and is a Debian derivative. But one of the main benefits over Debian itself is that the apt repositories receive updates faster. Debian is more enterprise-ish with their release cycles, Ubuntu is more bleeding edge.

The latter makes it particularly useful for software development, as you generally want to test things against recent versions of software. But like ADmad said, nothing is stopping you from spinning up your jobs in a Debian container if that's more your thing.

@kaylangan
Copy link
Contributor

@johannbg thanks for sharing your thoughts and feedback.

We do not plan to support other Linux distros. As others have mentioned, Docker is great for this purpose. We'd suggest using Docker for the distros you desire.

@johannbg
Copy link
Author

For the first this is relevant to a specific "runs-on" feature of actions so I dont see the relevance to docker or how or why you presume everybody is using docker when there are better supported, cross distro tools like mkosi that does a better job of creating bootable containers/vm images from scratch.

And it's not what Ubuntu needs but what Canonical/Ubuntu does to maintain the distribution and behaves in the linux ecosystem

If you want to test things against recent versions of software the bleeding edge distro these days is Arch presumably followed by Fedora while RHEL/CentOS ( streams ) SLES/Ubuntu LTS do not so that technical argument is mute ( the argument of we chose Ubuntu because it runs newer software than any other linux distribution does ) or the distribution you are targeting you application or application stack for.

In anycase what is the technical reason for not supporting more distributions and why was Ubuntu chosen the default and duh it runs on other platforms or others are using it is not an answer.

There was a meeting right, someone suggested let's just use Ubuntu made his case in front of the git hub audience,

@johannbg
Copy link
Author

Why do you not plan to support other Linux distros what's the argument for not doing so and why was Ubuntu chosen?

@oldskool
Copy link

Why do you not plan to support other Linux distros what's the argument for not doing so and why was Ubuntu chosen?

Let's turn the question around. Why do you need other Linux distros? What does the Ubuntu instance refrain you from doing that another distro would allow you to do? If you have valid reasons to need other distributions on top of Ubuntu other than personal preference, I'm sure that GitHub would be open for suggestions and your input.

But this is not the place to debate all the technical choices made by GitHub. We could also debate why Actions instances run on Azure instead of Google Cloud or AWS. And we could debate why the hypervisors run on Hyper-V instead of VMWare. Of course the answer to these questions is clear, but that's not really the point. It's a discussion that's very out of scope for an issue if it doesn't impact the way that Actions allows you to do things.

@johannbg
Copy link
Author

If this was my personal preference I would just have mentioned one Linux distribution and left out the others and mentioning and referring to the Azure official guest images ( which include Ubuntu ) but might been a valid technical limitation ( we are bound to provide ( and even run on ) what Azure officially supports ).

Compliance might be one such reason in which one might want to ( or have to ) run anything related to the infrastructure either self hosted or virtual machines running specific OS instance ( Windows/Linux/OS-X ) running the workflows which you point to or on a platform that meets such compliance or legal requirments. Such feature could be implemented behind a paywall such as "GitHub Enterprise" while the rest of the world would be stuck with Ubuntu as their only option but given that "We do not plan to support other Linux distros" you ( read as github ) don't even seem to be considering providing alternatives on github's enterprise side of things or compliances has been a low hanging fruit on the github actions table.

@oldskool
Copy link

run anything related to the infrastructure either self hosted or virtual machines running specific OS instance

And that will be possible since self-hosted runners are becoming available prior to the GA in november. So if you feel like you need to run your Actions runners on Debian, Arch or whatever OS that's not Ubuntu, go right ahead and do it.

@johannbg
Copy link
Author

I was unaware of that possibility and thanks for pointing that out. That most certainly will make things easier from compliance and security perspective.

@andyfeller
Copy link

And that will be possible since self-hosted runners are becoming available prior to the GA in november. So if you feel like you need to run your Actions runners on Debian, Arch or whatever OS that's not Ubuntu, go right ahead and do it.

It would have been appreciated if this was the initial reply rather than all the back and forth.

@jiridanek
Copy link

For anybody wondering how to run a workflow in a docker image, the answer is https://docs.github.com/en/free-pro-team@latest/actions/reference/workflow-syntax-for-github-actions#jobsjob_idcontainer. You'd use ubuntu image in the runs-on, but then you also specify a container to be started on that ubuntu, to run your steps.

@ekohl
Copy link

ekohl commented Oct 2, 2020

pulp/pulpcore-selinux@41d4bba is an example of how to compile SELinux policies on CentOS 7 and 8. Since it's still running on an Ubuntu kernel, you obviously can't actually load the policy to see if it would work. A real VM is needed for that. However, it can provide a decent base line test.

@MTecknology
Copy link

The Mac image comes with virtualbox, so if you really need to use something else on github's hardware, you can use that.

FreeBSD - https://github.com/vmactions/freebsd-vm

It takes a lot longer to run the tests, but it works great. It seems like a fair compromise between github focusing on security, stability, and overall quality of the few images they're supporting and our ability to abuse their hardware with trillions of tests. :D

@jsirianni
Copy link

a discussion that's very out of scope for an issue if it doesn't impact the way that Actions allows you to do things.

I would like to test RPM installation for one.. On a system that is native (not a container) due to dependence on systemd. Yes we can run systemd in a container, but it is painful and not representative of a real system in a customer environment.

@radiomix
Copy link

@oldskool

Let's turn the question around. Why do you need other Linux distros

AWS EC2 instances come with AWS linux: It would be nice to run Github Actions on an AWS-like OS.
Seems as if Github - aka MicroSoft aka closed-source - and AWS are competitors, hence . . . ;-(( we woun't see any progress here.

Probably also holds true for:

Why do you not plan to support other Linux distros what's the argument for not doing so and why was Ubuntu chosen?

This all reminds me of the 90s when monopoly IT big evil was . . . .

ms

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

10 participants