#random (2022-01)

Thank you for the incredible response for individuals that have reached out to sign up to participate as a guest on our upcoming podcast missionCTRL! Our sign up page is live. https://vh2q7l1thkr.typeform.com/missionCTRL

missionCTRL is a podcast (and sometimes livestream) series for DevOps Engineers.

The line up of guests is world class featuring a healthy mix of technical deep-dives and other topics beneficial to the community (getting started in DevOps, managing mental health and stress as an engineer).

Great idea! Curious what you use on the backend?

(don’t hate me )

TBH, i’m trying to keep that undercovers since that’s kinda the secret sauce

No problem

I bet you built something on top of python 3.

Maybe asincio + websockets library? https://websockets.readthedocs.io/en/stable/

I’d love to see a comparison of performance between various implementations, Go channels, elixir channels, something in rust…

NATs?

https://github.com/nats-io <– better context for my last obtuse statement

you guys all rock. Yea, performance is going to be junk since it’s just running on a t4g.micro instance

just wanted to see if anyone would use the api for anything.. https://go.plz.chat

if people like it, i’ll scale up, but would rather not throw money out the window for nothing

Did you try emailing them? Har Har Har

I think I fell in love

Finally, a looking-good make alternative

it actually works

wtf? So confused right now.

don’t worry, not the master branch. You can check the link in the README in the link above to know more

Sure, but still wonder why this commit exists.

to show that you shouldn’t fully trust github? https://news.ycombinator.com/item?id=24976138

i mean, like anything, validate your sources, right? like, just cuz this email says it is from Amazon, what evidence is it and my email client presenting where i would trust that is true?

don’t trust anyone, except yourself. And maybe your future self

my future and past selves are pretty suspect

Amazing

There’s no initiative to replace the build harness

What you might be thinking of is atmos

We are looking to reintroduce basic workflows in atmos, but not to compete with full fledged task runners like gotask, mage, variant

Got you. So what are you using for stuff beyond basic run commands? Bash scripting in make or something else now?

Spacelift :-)

Basically it’s a policy based approach rather than a scripted approach

The policy is if A changed then B is affected so replan B

That way it works more like a graph

That’s cool for workflows. I’m talking about all the stuff in between.

Like a team member clones a repo, and they need terraform, linters, Go, etc, and then they need to run sets of tasks before merging back up.

I’m curious if you are continuing with build-harness as the way to wrap up tooling for team members. Also curious if run all the same tests (that you can) locally before github actions gets involved, or you offload stuff to github actions instead for running checks. No rush, just wondering. I want to do a write-up some type as a lot of this in between CI/Dev experience isn’t written about much and it’s pretty impactful depending on the complexity (esp at an enterprise company)

I’m curious if you are continuing with build-harness as the way to wrap up tooling for team members. It was really only for us to simply CI/CD of our OSS terraform infra

Btw, have you seen https://sweetops.slack.com/archives/CQCDCLA1M/p1643291095262819

Yes I have! It’s pretty cool. I tried it a bit at home. They have a fantastic tech blog too.

Like a team member clones a repo, and they need terraform, linters, Go, etc, and then they need to run sets of tasks before merging back up. Yes, this is true… this is something we’re using build-harness for

Cool! As I’ve been working in the Go ecosystem I’m lucky as most tools are cross platform. I am using Mage and with the magetools repo I created now most of the generic things I want on github or any project is a 1 line import.

mage init i think is sorta like your build harness init.

We aren’t adding too much to it today. I think build-harness is due for a refactor.

I’m a big fan of Mage having tried so many things so if you like writing in Go, I’d love to show you sometime what I’ve been doing with it.

My favorite part recently is that instead of running install/setup, I’ve begun having each task that calls a tool, lets say Goreleaser, do this stuff https://pkg.go.dev/github.com/sheldonhull/[email protected]/pkg/req

So basically like this task, if the go binary can’t be found and fully qualfiied, the task itself attempts to install it automatically. So you could type mage go:fmt and even if tools are missing it self sets up.

https://github.com/sheldonhull/magetools/blob/5c8f7f500e37f0569bc2999166a150458d6e7d44/gotools/gotools.go#L152-L158

I’m beginning to like this approach vs require all tooling and stuff be setup prior.

My favorite part about this is that moving to CI (for me Azure Pipelines) then is as simple as:

                  - bash: |
                       mage pulumi:up ${{ parameters.PROJECT}} ${{ parameters.ENVIRONMENT }}
                    displayName: mage pulumi:up ${{ parameters.ENVIRONMENT }} ${{ parameters.ENVIRONMENT }}
                    timeoutInMinutes: 5
                    env:
                      PULUMI_ACCESS_TOKEN: $(PULUMI_ACCESS_TOKEN)
                      MAGEFILE_HASHFAST: 1

For me being able to iterate locally first and then just reuse the same work instead of relying on more plugins is super cool.

I need to reinvestigate your build-harness to examine the docker stuff. I wrap up some tools in docker, but need to decide if I want docker to be a true dependency. In that case I could wrap up more non-go tools (the hard ones) in docker run commands. I did this for the azure-cli but haven’t tried to extend, mostly relying on asdf instead. I did look at env-cli which was super cool, but didn’t seem as widely used or active as I wanted before I dived in.