cov: let callers select data stores

[aberoham]

could the shared coverage workflow take a data-stores input, for example mysql,json?

NicTool/api#61’s mysql-only report was 86.87%, so Codecov’s project check fails against main’s current 88.67%. The JSON coverage run passes ~546 tests with one mysql-only race test skipped and currently reports 90.56%; it covers the file-store paths the default run misses.

Running both requested stores and uploading both lcov reports for the same commit would let Codecov combine them.

[msimerson]

I don't see why not.

[msimerson]

The key to solving codecov in api was pinning node to version 24 (already solved here).

[msimerson]

Aside: a 2-month contract lured me out of semi-retirement and I'm pretty focused on that ATM. Reviewing little PRs is pretty easy and quick, big ones are...frequently more than I have capacity for. Next week it's back to holiday and time away from screens of all shapes.

[aberoham]

Further asides:

For the big ones, if you offer off-the-cuff quips around how you prefer that they be chunked up into smaller logic units, it's actually pretty interesting to me to see what the clankers attempt to do and how well they achieve that stated human preference -- I'd use each of those "meatproxy" reactions as an opportunity to improve the harnesses and tests. If you have more broad generalisations of how best to chunk things, I'd attempt to enshrine those in the non-deterministic guidance and even the more strict linters that are coming together within metarepo (e.g. NicTool/metarepo#20).

My areas of focus, besides tidying up my decades old self-hosted instances and a random powerdns or two scattered about in oft-forgotten business units, all revolve around corporate/enterprise day-to-day, leaning heavily into security and hyperscalers:

• import/export and wrangling of many-dozen-contributor IBM NS1 practice that's mostly nowadays handled by pipelines but still has some break-glass "hands in the cookie jar"
• wrapping up random straggler practices within other managed services, incl Route53, GCP Cloud DNS, Cloudflare, Fastly (secondary pull-only) and even Azure DNS (shivers). For some of these I even may need continual bi-directional sync (not just one-off import and export)
• tools that catch security & hygiene smells, particularly lame delegations and common TXT record data-level mistakes
• alternative control-plane deployments, perhaps "cheap" ways of running within CF Workers, GCP CloudRun and similar substrates that don't require long-lived VMs
• abusing the squeaky-clean and efficient v3 layers as a simple GUI-less agent-friendly interface to all of these otherwise foot-gun prone DNS authority systems where I really don't want to hand out broad access to non-greybeards, much less to "frontier" models
• creating an LLM eval suite so we could perhaps all see which of these frontier models actually understands DNS the best, incl how that evolves over time (check out TerminalBench if you want to fall down this rabbit hole, it's pretty neat)

[msimerson]

I'd add to your list:

• tiny one-off DNS instances with "home" type features:
  • a curl API for updating dynamic DNS hostnames (no/min/IP auth)
  • DHCP/SLAAC integration

General rules for PRs (same for agents as humans): create smaller, focused pull requests with clear and informative titles and succinct descriptions of what changed and why. For Agents: drop the narration. Say each fact worth saying exactly once. Humans time and attention are both finite: limit the information to only what is necessary. After writing the body, rewrite it dropping 40% of the words while preserving the meaning. Repeat again.