Like many of you, I struggled with automating Dependency-Track. Using curl was messy, and my dashboard was flooded with hundreds of "Active" versions from old CI builds, destroying my metrics.

I built a small CLI tool (Go) to solve this. It handles the full lifecycle in one command:

Uploads the SBOM.

Tags the new version as Latest.

Auto-archives old versions (sets active: false) so only the deployed version counts toward risk scores.

It’s open source and works as a single binary (or Docker image). Hope it saves you some bash-scripting headaches!

Repo: https://github.com/MedUnes/dtrack-cli

done, MIT.

Hi and thanks so much for the feedback here

If I got it right, the summary is as such:

1- License: I'll add soon, forgot about it (literally)

2- Where is the solution: I hope you all read the contributing guide, I clearly mentioned solutions are not the MAIN point for this repository, it is rather giving problems which are intended to *guide* me/you through hands-on practical constraints on how to face those "go" weird scenarios. I also clearly stated I'm not that much top notch Go dev to provide you with solutions for now

3- No, this is neither chatgpt, nor claude code generated repo.

4- I'm till waiting until someone with enough experience that worked on these problems in real life can either suggest solutions or provide support

5- The project is a hands-on documentation, maybe on-going process. IMHO is better (for me at least) than a youtube video that I forgot about the next day. Struggling into the problem and implementing an okkeyish solution would force me ask and search for the foundational knowledge behind it, read books *with this goal in mind*, what videos *with that intention*, and so on. I'm very hands-on learning person.

6- Would be very nice to have these questions here in form of Github issues as well, then maybe seasoned devs can support both me and you better

7- I haven't expected it to escalate to ~ 1.7k stars in two weeks, with not much effort, and this is IMHO a proof many devs struggle with that exact gap I'm trying to tackle

I’ve been transitioning to Go after years in other ecosystems, and kept running into the same problem: I could write correct Go code, but not idiomatic Go.

Most material focuses on syntax or algorithms. In practice, what caused friction were production mismatches: context cancellation and goroutine leaks, errgroup vs WaitGroup tradeoffs, HTTP client hygiene, error wrapping semantics, allocation control, embed/io/fs for dev–prod parity, etc.

I started collecting small, constraint-driven katas that isolate one such mismatch at a time. Each kata defines explicit pass/fail idiomatic constraints, rather than providing solutions. The goal is deliberate practice, not “best practices” or tutorials.

This repo is curated by someone transitioning to Go, for others doing the same. It’s not meant to be authoritative. If you’re experienced with Go and spot incorrect, unsafe, or misleading constraints, issues and PRs with rationale and references are explicitly encouraged.

I’m especially interested in feedback from people using Go in production on where these constraints are wrong, incomplete, or missing important edge cases.

What is the difference between a "prod grade kata" and a practice project?

I fail to see the value to someone transitioning to Go if there aren't any reference solutions.

How would one know if one's code is idiomatic, without either a reference or someone to ask?

And if you have someone to ask, what's the point of this repo?

I've just created #PHP Noise!, a starter-kit for your [opensource] PHP projects. It includes frequently needed boilerplate setups (badges, tests, #phpstan, #sonarqube, #psalm, #phpunit, #travisCi readme, license, contribution, logo etc..)

Tom from Codecov here, looks awesome! Thanks for building this out.