Jonathan Amsterdam would like Hyang-Ah Hana Kim and Ethan Lee to review this change.
internal/postgres: clean generated buf.build modules
module paths beginning with "buf.build/gen/go" seem to account for
about 4% of new modules, but they appear in the proxy as a side effect,
apparently, and nobody particularly cares about their documentation as
far as we know. So remove them from the DB.
We do it as part of cleaning instead of a one-off bulk delete so that
it's permanent, in case more such modules get inserted, and so that we
have an easy-to-fid artifact.
diff --git a/internal/postgres/clean.go b/internal/postgres/clean.go
index 9968747..3cf51ad 100644
--- a/internal/postgres/clean.go
+++ b/internal/postgres/clean.go
@@ -14,6 +14,8 @@
"golang.org/x/pkgsite/internal/derrors"
)
+const bufBuildPrefix = "buf.build/gen/go"
+
// GetModuleVersionsToClean returns module versions that can be removed from the database.
// Only module versions that were updated more than daysOld days ago will be considered.
// At most limit module versions will be returned.
@@ -47,11 +49,13 @@
WHERE requested_version IN ('master', 'main', 'dev.fuzz')
) vm_filtered ON m.module_path = vm_filtered.module_path AND m.version = vm_filtered.resolved_version
WHERE
+ (
m.version_type = 'pseudo'
AND CURRENT_TIMESTAMP - m.updated_at > make_interval(days => $1)
AND latest.path IS NULL
AND sd.module_path IS NULL
AND vm_filtered.module_path IS NULL
+ ) OR m.module_path LIKE '` + bufBuildPrefix + `%'
LIMIT $2
`
diff --git a/internal/postgres/clean_test.go b/internal/postgres/clean_test.go
index eeab9ea..a781210 100644
--- a/internal/postgres/clean_test.go
+++ b/internal/postgres/clean_test.go
@@ -26,12 +26,14 @@
want := []string{
"a...@v0.0.0-20190101000000-abcdef012345",
+ bufBuildPrefix + "a...@v1.0.0",
}
for _, mv := range append(want,
// These should not be cleaned.
"a...@v1.0.0", // tagged
"b...@v0.0.0-20190101000000-abcdef012345", // latest version
"b...@v0.0.0-20180101000000-abcdef012345", // 'main' in version_map (see UpsertVersionMap below)
+ "buf.build/gen/a...@v1.0.0", // non-gen buf.build module
) {
mod, ver, pkg := parseModuleVersionPackage(mv)
m := sample.Module(mod, ver, pkg)
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Kokoro presubmit build finished with status: SUCCESS
Logs at: https://source.cloud.google.com/results/invocations/9b55f24a-da4a-4e32-91c9-69ddf1328fa9
| kokoro-CI | +1 |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
const bufBuildPrefix = "buf.build/gen/go"This should have a short comment explaining why we have this prefix.
bufBuildPrefix + "a...@v1.0.0",Consider using the literal string here to ensure that the test independently verifies the value used by production code.
bufBuildPrefix + "a...@v1.0.0",This results in the string 'buf.build/gen/g...@v1.0.0'. Include a slash: bufBuildPrefix + '/a...@v1.0.0'?
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
This should have a short comment explaining why we have this prefix.
Done
Consider using the literal string here to ensure that the test independently verifies the value used by production code.
Done
This results in the string 'buf.build/gen/g...@v1.0.0'. Include a slash: bufBuildPrefix + '/a...@v1.0.0'?
Done
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Kokoro presubmit build finished with status: SUCCESS
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
internal/postgres: clean generated buf.build modules
module paths beginning with "buf.build/gen/go" seem to account for
about 4% of new modules, but they appear in the proxy as a side effect,
apparently, and nobody particularly cares about their documentation as
far as we know. So remove them from the DB.
We do it as part of cleaning instead of a one-off bulk delete so that
it's permanent, in case more such modules get inserted, and so that we
have an easy-to-find artifact.
We don't try to clean all excluded modules because what if someday
somebody wants to unexclude something? That could result in a lot of
work. But maybe that's not a good argument. Maybe we should be cleaning
them.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |