#random (2021-08)

I would like to add two more cli commands:

• sed

• jq these two play important roles when updating files or reading json from output command, almost every devops cli tools produce json, and some times you need to read a value

Thanks @Mohammed Yahya I will add them when i get a chance

Sadly it’s sooo true

terraform! DevSecOps!

especially important in consulting that we help customers understand we’re not solving fundamental problems of their application

My favorite phrase is “How much will it cost for us to get DevSecOps?”

My latest Zoom background

I’ve had the one on the left for a long time. Just added the one on the right. You inspired me

heh, ruby that generates YAML, that will be used to generate bash?

Why not https://github.com/mumoshu/variant2 ?

I did a dive into this reproducing the behavior for terraform deployments that Atmos did.

If you have any programming experience in python, Go, or other language that builds good workflows/CLI tools I’d suggest that variant while promising will be very tedious to rebuild entire workflows in.

Not saying it doesn’t hold value, but for me I found it very inhibiting compared to just adding some Taskfile.yml or in my other case Mage (go based task runner) tasks. Yes, it’s not the same as defining in HCL, but honestly I really don’t want to normalize specialized tools in HCL if I can avoid it. If you are dealing with a ton of contributions from others with different languages and tools, it’s just easier to write the commands in your own task framework IMO.

Hope that is somewhat useful. I did give it a shot, but I think even Cloudposse is moving away from variant for their own Go based runner too, so likely they had a similar experience with just coding vs using another DSL to wrap up tools.

yeah i’d recommend writing go instead of custom hcl/yaml config if you’re keen to learn go

other go-based task runner like mage is also great. i’ve tried that myself. one complaint is that writing a testable magefile was hard for me.

so here’s my next trial: https://github.com/mumoshu/gosh

Nice! So I guess the testability is a question for me right now. If I write tests for a bunch of wrappers around shell commands things get crazy trying to test. I’m ok with just returning the error in most cases, which mage provides very simply.

For a more “pure” Go based approached, Goyek is a pretty awesome project as well, that follows the testing interface pattern. it’s more idiomatic Go.

My challenge is that I’ve needed to balance adhoc quick fast tasks with the fact that Go isn’t really meant to be written that way. Mage seems to handle the middle path ok.

I’m been standardizing basic tasks here and able to reuse them. These are not very sophisticated but removed my dependency on most of my taskfiles as a first step.

https://github.com/sheldonhull/magetools

I’m happy with the nice polish it gives folks. For example, if you forget to use the .env.example to bootstrap during setup, my mage compose:up task will actually prompt you and ask you to choose a file to copy to .env to use as a starting template.

Some of this is hard to test like typical Go code, but it’s still a big improvement over trying to write this in a hamstringed shell interpreter in Task.

I was pretty proud of this simple developer workflow tweak to help reduce head scratching and wasted time in setup.

@mumoshu very cool with Gosh. I starred it and will keep it in mind especially if I see some end to end testing needed in the future. thanks!