xjia

Indeed. We are already optimizing this. And spot instances are coming soon as well :-)

Before this we were using https://github.com/actions/actions-runner-controller but that's running on K8s instead of VMs. So along with common limitations of running CI jos in K8s/container, it cannot have exactly the same environment as the official GitHub runners. Maintaining a K8s cluster was also very difficult.

Persistent disks are implemented as EBS snapshots, so the process is something like:

1. Create EC2 instance for runner #1. Find out there is no existing snapshot, so an empty volume is created and attached.

2. Runner #1 runs exactly 1 job and shuts down. A snapshot is taken for the persistent volume. That's going to be used by later runners.

3. Create EC2 instance for runner #2. Create a new volume based on the last snapshot.

4. Assuming #2 is still running while a new job comes in. Create EC2 instance for runner #3. Create volume based on the same last snapshot.

5. Whenever a runner finishes, its persistent volume gets a snapshot taken. Outdated snapshots are automatically removed.

And yes we manage the AMI that the runner uses. We try out best to follow https://github.com/actions/runner-images and will automate this process very soon so it's always up-to-date.

Edit: formatting

We are working on an alternative that's 100% compatible with GHA but much cheaper and faster. Check out https://dime.run/

From [0]:

gShoe is an internal joke about a product [Google] shouldn't make, and is used in many internal trainings as a placeholder for any Google product

[0] https://www.reddit.com/r/google/s/fHCBJipqdP

IIUC the actual computation (e.g. compiling, linking, ...) happens on client (CI or developer) machines and the results are written to the server-side cache.

By spoofing I meant to say that an authenticated but malicious client (intentionally or not, e.g. a clueless intern) may be able to write malicious contents to the cache. For example, their build toolchain could be contaminated and the resulting build outputs are contaminated. The "action" per se and its hash is still legit, but the hash is only used as the lookup key -- their corresponding value is "spoofed."

The only safe way I can imagine to use such a remote cache is for CI to publish its build results so that they could be reused by developers. The direction from developers to developers or even to CI seems difficult to handle and has less value. But I might be missing some important insights here so my conclusion could be wrong.

But if that's the case, is the most valuable use case to just configure the CI to read from / write to the remote cache, and developers to only read from the remote cache? And given such an assumption, is it much easier to design/implememt a remote cache product?

What is the benefit of using a remote cache instead of a local ~/.cache directory? Is it only for sharing build results among team members? How do you make sure the build results are not spoofed?

Awesome! If there is any problem just post it in GitHub issues. We will also be releasing 2023.4 very soon.

Yes, the code of the analyzer itself cannot be built on macOS or Windows directly. In those cases you will have to use either podman or docker to use the binaries prebuilt on/for Linux. The whole system depends on a lot of other stuff on Linux so it won't easily run on other OSes.

That's running the prebuilt container image. The README has instructions on how to build from source.

I'm not sure about the timeline because that depends on a lot of things. In the meantime I guess you could start with AUTOSAR C++14. MISRA C++:2023 is essentially built on top of that.

For enterprise edition simply email to hello[AT]naivesystems.com as noted in the README on GitHub

If you build it from source it's actually a bunch of regular executables. Running as a container is for the purpose of making the environments hermetic/reproducible so that it's easier to support users.

No. Using GPL software has nothing to do with the code processed by it. Think about the GCC compiler :)

Clang has its own limitations. And it takes more effort than just writing the checkers. We open sourced our previously proprietary static analyzer (mostly based on Clang but also integrated other useful tools) but the commercial/enterprise edition still has its own value in stability, quality assurance, and technical support. It's more like building a Linux distro (e.g. RHEL) from various FOSS components.

2023 is supported in the enterprise edition but not in the community edition yet. We gradually move features from EE to CE as new features added to EE. So you can expect 2023 support in CE in the future :-)

If you are interested in this, take a look at NaiveSystems Analyze [0] which is a free and open source static analyzer for checking MISRA compliance etc.

Disclaimer: I'm the founder.

It has been battle tested with real customers in automotive, medical devices, and semiconductors. AFAIK this is the first FOSS tool that achieves commercial use standards (extensive ruleset coverage, low false positives based symbolic execution (which Coverity relies heavily on) and SMT solver, ...)

[0] https://github.com/naivesystems/analyze

Yes I totally understand the concern. We are actively working on SOC 2 and other compliance stuff to help with this. But honestly I feel the compliance requirements are weaker than what we actually implemented. For example proper secure boot and whole disk encryption (without sacrificing performance) are mandatory in our mindset but these specific things don't get reflected in compliance.

Instead of being a service, I'm also open to sell the software+hardware solution behind it, so you can have it on-prem. Do you think that's something you would consider given the constraints on supply chain security?

I had a similar experience with ARC (actions-runner-controller).

One of the machines in the fleet failed to sync its clock via NTP. Once a job X got scheduled to it, the runner pod failed authentication due to incorrect clock time, and then the whole ARC system started to behave incorrectly: job X was stuck without runners, until another workflow job Y was created, and then X got run but Y became stuck. There were also other wierd behaviors like this so I eventually rebuilt everything based on VMs and stopped using ARC.

Using VMs also allowed me to support the use of the official runner images [0], which is good for compatibility.

I feel more people would benefit from managed "self-hosted" runners, so I started DimeRun [1] to provide cheaper GHA runners for people who don't have the time/willingness to troubleshoot low-level infra issues.

[0] https://github.com/actions/runner-images [1]: https://dime.run

If you are interested in persistent cache, maybe take a look at https://dime.run

We have persistent disks support in https://dime.run

We support machines with large core counts in https://dime.run so check it out :)

We are essentially competing in the same space with https://dime.run/

We also use VMs. But they are persistent. So you always see your runners as Online in GitHub UI.

We achieve this by investing in virtualization technology so that idle runner VMs do not consume too many resources. Disclaimer: I used to work for Google Cloud.

Or base58, e.g. https://api.rubyonrails.org/classes/SecureRandom.html#method...

We are slowly onboarding customers in batch. The waitlist is for batching, not because the service is not ready. We do need more traffic to get better efficiency and predictability in batching.

Check out https://dime.run/ if you need something for Github actions

Are you aware of symbolic execution?

Because it's 10GB not 10TB?

https://dime.run/

We host GitHub Actions runners for you, with faster CPUs and larger storage at lower prices than the official ones. Currently running a waitlist and onboarding customers in batch to validate the idea.

Diff between 1.0.0 and 2.0.0

https://github.com/semver/semver/compare/v1.0.0...v2.0.0

Check out https://dime.run/ they manage workers for you