There was no way to run the whole platform locally, so I wrote a small Go CLI that renders plain docker compose projects from a service catalog, and most of what I learned had nothing to do with compose.
A generic credential resource works, and it puts the whole burden of knowing what goes inside on whoever writes the terraform.
Access levels arrive in GitLab releases, so validating them without knowing the version gets you a plausible error at the wrong time.
Every AWX quirk used to mean another branch in a template. Now it's a field on a config struct.
The AWX API describes every resource, so the provider is thirteen templates and a config file that says where the description lies.
AWX changes its API between releases, so the provider has to know which release it was generated from.
AWX describes its own resources if you send it an OPTIONS request, so writing the schemas by hand was work I did not need to do.
GitLab tokens live in CI variables for a year at a time, and nobody remembers which ones are still there.
AWX has a perfectly good API, but managing it by hand stops scaling the moment more than one person touches it.
Last time in were exposing some metrics for a golang application, but exposing the data is useless without having a way to visualise it or even store it somewhere in a location so we can analyze...
Quite often we are found with a challenge to troubleshoot something in production, or to see why is our application slow, or why isn't it serving requests fast enough.
A lot of times it's useful to expose metrics for your application so you can know what is going on with the application, there are two ways you can do this one it's either using a pull or a push...
Some of my services were written in Go, and we wanted a way to track which version was used, so we can track and solve issues. Or even see when the application was deployed or from which source...