- cd into repo

- `flox activate` -> puts you into a subshell with your desired tools, environment variables, services, and runs any setup scripts you've defined

- You do your work

- `exit` -> you're back in your previous shell

Setting up and managing an environment is also super easy:

- cd into project directory

- `flox init` -> creates an "environment"

- `flox install python312` -> installing new packages is very simple

- `flox edit` -> add any environment variables, setup scripts, services in an editor

- `flox activate` -> get to work

The reason we call these "environments" instead of "developer environments" is that what we provide is a generalization of developer environments, so they're useful in more than just local development contexts. For example, you can use Flox to replace Homebrew by creating a "default" environment in your home directory [2]. You can also bundle an environment up into a container [3] to fit Flox into your existing deployment tools, or use Flox in CI [4].

All that stuff I described is free, but we have some enterprise features in development that won't be, and I think people are going to find those very appealing.

[1] https://flox.dev

[2] https://flox.dev/docs/tutorials/migrations/homebrew/

[3] https://flox.dev/docs/reference/command-reference/flox-conta...

[4] https://flox.dev/docs/tutorials/ci-cd/

When I they did, I said "fuck it" and just started distributing a Nix flake with wrappers for all the tools I want to run in CI so that at least that part gets handled safely and is easy to run locally.

The worst and most annoying stuff to test is the CI platforms' accursed little pseudo-YAML DSLs. I still would like that piece.

devenv.sh tasks might be a good basis for building on it. I think maybe bob.build also wants to be like this

/me puts tinfoilhat

https://gitea.com/gitea/act -> https://gitea.com/gitea/act_runner

https://code.forgejo.org/forgejo/act -> https://code.forgejo.org/forgejo/runner

https://github.com/jenkinsci/jenkins/tree/master/.github/wor...

Managing the underlying infra is painful, and it remains a security liability even when not making obvious mistakes like exposing it to any open network.

And good luck if you're having that fun at a windows shop and aren't using a managed instance (or 5).

This is what Earthfiles look like: https://docs.earthly.dev/docs/earthfile

Turns out CI/CD is not an easy problem. I built a short-lived CI product before containers were really much of a thing ...you can guess how well that went.

Also, I'll take _any_ CI solution, closed or open, that tries to be the _opposite_ of the complexity borg that is k8s.

It's inevitable that things will be more difficult to debug once you're using a third party asynchronous tool as part of the flow.

CI must be local-first and platform-agnostic.

How do you figure that? I'd buy "lock people in the platform," but in that way GitHub Issues has been the moat for far longer than Actions has

The trap and tradeoff is that the thirtieth time you’ve done that is when you realize you’ve screwed yourself and the organization by building this Byzantine half baked DAG with a very sketchy security story that you can’t step through, run locally or test

Pour one out, I guess, but it's okay since I previously was super angry at it for languishing in the uncanny valley of "hello world works, practically nothing else does" -- more or less like nektos/act and its bazillions of forks

nu is my default shell. Note that I am not talking about dagger shell. https://dagger.io/blog/a-shell-for-the-container-age-introdu...

GitHub Actions' macOS runners do not come with Docker installed, because of licensing issues: https://github.com/actions/runner-images/issues/17

Then there is the issue that the macOS runners are virtual instances, and pass-through virtualization has not been enabled:

https://github.com/douglascamata/setup-docker-macos-action#:...

In my experience, GitHub Actions work quite well, especially for smaller projects or when you can avoid using public templates and actions. While shortcuts like third-party libraries or actions can be convenient, they often come with trade-offs.

For scenarios where having your own runners and build images is beneficial, I would recommend GitLab CI.

Jenkins is a great choice if you need to run builds on dedicated hardware or within a virtualized environment.

When discussing the challenges of CI/CD, I often notice that many issues stem from complex chains of dependencies within the software or product itself. For example, consider a release pipeline that typically takes six hours to complete but fails after four hours. In such cases, having to restart the entire pipeline instead of just the failed job can be quite inefficient.

Additionally, debugging can become much easier when you have your own build images on runners, as you can run them locally for testing and troubleshooting.

What specific aspects of CI/CD do you find broken or challenging?