Structural updates

[gwynne]

Enables Dependabot, adds more CI, and cleans up a couple things.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 76.71%. Comparing base (f294b62) to head (4b9f9b1).

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #634      +/-   ##
==========================================
- Coverage   76.75%   76.71%   -0.05%     
==========================================
  Files         135      135              
  Lines       10391    10391              
==========================================
- Hits         7976     7971       -5     
- Misses       2415     2420       +5     

see 2 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[github-advanced-security]

You are seeing this message because GitHub Code Scanning has recently been set up for this repository, or this pull request contains the workflow file for the Code Scanning tool.

What Enabling Code Scanning Means:

• The 'Security' tab will display more code scanning analysis results (e.g., for the default branch).
• Depending on your configuration and choice of analysis tool, future pull requests will be annotated with code scanning analysis results.
• You will be able to see the analysis results for the pull request's branch on this overview once the scans have completed and the checks have passed.

For more information about GitHub Code Scanning, check out the documentation.

[fabianfett]

what does this do?

[gwynne]

It implements https://docs.github.com/en/code-security/how-tos/secure-your-supply-chain/secure-your-dependencies/using-the-dependency-submission-api

[fabianfett]

cool. but that's only important for leaf packages, isn't it? I assume this works on the Package.resolved, and this can look very different based on the checkout.

[gwynne]

No, it matters for libraries too, it helps Dependabot to determine whether you're affected by security advisories in dependencies. Yes, it's dependent on the most recent versions released at the time the submission job runs, since there's no lockfile in the repo (and yeah there can be platform-specific dependency issues too), but it's still better than nothing at all for the notices about security issues so you can update the minimum requirements in Package.swift. (Also, I believe the tool I'm currently using for dependency detection yields all deps, not just "currently active" ones—it's an SBOM generator, after all. I'll be switching to using the one that's now built into SwiftPM when it's available, which will actually be kind've annoying because that doesn't have a native "Github Dependency Submission API JSON" output mode like the third-party tooling does. 😆)

[fabianfett]

Yes, it's dependent on the most recent versions released at the time the submission job runs, since there's no lockfile in the repo (and yeah there can be platform-specific dependency issues too), but it's still better than nothing at all for the notices about security issues so you can update the minimum requirements in Package.swift

But this means, that for tests we will always pick the latest version, and if there is a security advisory, by definition we will pick the version that has the issue already resolved.

[gwynne]

For tests, yes. But if you don't update the minimums in Package.swift, downstream users can end up with transitive dependencies that don't get updated because of some other requirement in the graph or just because SwiftPM hiccups (I've seen both scenarios in the real world multiple times).

[fabianfett]

but that would never be caught here, because Package.resolved is always using the latest and greatest.