Move cargo-deny into a separate workflow on a schedule

[jcgruenhage]

Problem

There are two (related) problems with the previous handling of cargo-deny:

• When a new advisory is added to rustsec that affects a dependency, unrelated pull requests will fail.
• New advisories rely on pushes or PRs to be surfaced. Problems that already exist on main will only be found if we try to merge new things into main.

Summary of changes

We split out cargo-deny into a separate workflow that runs on all PRs that touch Cargo.lock, and on a schedule on main, release, release-compute and release-proxy to find new advisories.

[github-actions]

7403 tests run: 7017 passed, 0 failed, 386 skipped (full report)

---

Flaky tests (3)

Postgres 16

• test_metrics_normal_work: release-arm64-with-lfc

Postgres 15

• test_scrubber_tenant_snapshot[4]: release-x86-64-with-lfc
• test_metrics_normal_work: release-x86-64-with-lfc

Code coverage* (full report)

• functions: 33.5% (8488 of 25340 functions)
• lines: 49.3% (71418 of 144804 lines)

* collected from Rust tests only

---

_{The comment gets automatically updated with the latest test results
ae45eff at 2025-01-24T10:04:38.828Z :recycle:}

[arpad-m]

Great idea! We should probably talk about which team needs to ensure a "healthy" cargo-deny state, should it fail.

skip release-compute here, as this is not a rust release.

note that the the compute image includes rust components as well. Both postgres plugins written in Rust (which are built via git clone + cargo build, so are not managed by the Cargo.lock in this repo), as well as stuff from the compute_tools crate, which is managed by Cargo.lock.

[bayandin]

For PRs we don't want to have a separate workflow, but rather explicitly call a reusable workflow from the build_and_test workflow, reasoning is here:

neon/.github/workflows/build_and_test.yml

Lines 1257 to 1265 in 7d4bfcd

	# This job simplifies setting branch protection rules (in GitHub UI)
	# by allowing to set only this job instead of listing many others.
	# It also makes it easier to rename or parametrise jobs (using matrix)
	# which requires changes in branch protection rules
	#
	# Note, that we can't add external check (like `neon-cloud-e2e`) we still need to use GitHub UI for that.
	#
	# https://github.com/neondatabase/neon/settings/branch_protection_rules
	conclusion:

[jcgruenhage]

This makes the bit of filtering it to Cargo.lock changes a bit more complex, but is still doable. In some places we use tj-actions/changed-files (4 results), in others we use dorny/paths-filter (18 results). Should we standardize on one action for this?

[jcgruenhage]

https://github.com/neondatabase/neon/actions/runs/12931148735/job/36064437643?pr=10289 did not run cargo-deny, and https://github.com/neondatabase/neon/actions/runs/12931246215/job/36064743303?pr=10289 did.

Should I remove the anyhow bump again?