provisioning-backend VS earthly

I wrote a makefile which installs tools into PROJDIR/bin which is also in the gitignore.

Extremely simple in go, you just implement what is called Doer interface (one method). Here is an example from one of my projects, it is a simple decorator with logger in this case. Then you just initialize the client with this instance, in my project it is slightly more complex because I also setup OpenTelemetry but you get the idea.

Authentication and authorization is typically just a middleware which is essentially a function. Recently I implemented a RBAC functionality into our microservice which does not use any big framework. On our platform we have a RBAC service we need to call via REST. As you can see the whole patch is small if you exclude the generated OpenAPI client.

We use DAO/DAL in our app and I ran into the same problem - DAO does not work well with transactions. We have our own WithTransaction function which is currently only used within one model and that works fine. But the problem appears when we want to do a transaction across several models - that needs to be done in the business (service) layer.

Our project does have extensive makefile broken down into individual files so it is more readable. As you can see, we have targets for database, code quality, modules, testing, client generation, OpenAPI etc. It also has a trivial help:

Here is our code: https://github.com/RHEnVision/provisioning-backend/tree/main/pkg/worker

Our solution is simply one Redis queue, jobs have "type" (string) and are marshalled via Gob (for type safety) and there is no return value from job or error. This makes things extremely easy. We keep statistics (metrics) of job queue size and "in flight" jobs. Here is our implementation, just for inspiration. I suggest to write this on your own: https://github.com/RHEnVision/provisioning-backend/tree/main/pkg/worker

Also CACHE keyword, for cache mounts. Makes incremental tools like compilers work well in the context of dockerfiles and layer caches.

That can extend beyond just producing docker iamges as well. Under the covers the CACHE keyword is how lib/rust in Earthly makes building Rust artifacts in CI faster.

https://github.com/earthly/earthly/issues/1399

earthly

A few of us will be around to answer questions if anyone has any. I myself worked only worked on the chmod feature which was pretty trivial.

https://github.com/earthly/earthly/pull/1821

[2] https://github.com/earthly/earthly/releases/tag/v0.7.0

# cat Makefile BIN_PATH = $(shell pwd)/bin $(shell mkdir $(BIN_PATH) &>/dev/null) EARTHLY = $(BIN_PATH)/earthly earthly: ifeq (,$(wildcard $(EARTHLY))) curl -L https://github.com/earthly/earthly/releases/download/v0.6.23/earthly-linux-amd64 -o $(EARTHLY) chmod +x $(EARTHLY) endif

I started to bring awareness to the Earthfiles goofy license, but it seems they've switched to MPL! https://github.com/earthly/earthly/releases/tag/v0.6.15

The (unfortunately named) Dagger is also an entry into that space: https://github.com/dagger/dagger#readme (Apache 2)

- https://github.com/earthly/earthly/tree/main/analytics

Another *monster* difference is that Dagger is (at least currently) Apache 2: https://github.com/dagger/dagger/blob/v0.2.4/LICENSE but Earthly went with BSL: https://github.com/earthly/earthly/blob/v0.6.12/LICENSE

That means I'm more likely to submit bugs and patches to Dagger, and I won't touch Earthly

Example build steps for a go application