Recipe 4: Quarantine Debug Builds
This policy checks whether a package includes specific debug, test, or temp descriptors in the filename. This could be the simplest way for an organisation to state whether a package is a debug package, and therefore should not be ingested into, say, the production repository.
package cloudsmith
import rego.v1
default match := false
match if count(reason) > 0
reason contains msg if {
pkg := input.v0["package"]
re_match(".*(debug|test|tmp).*", pkg.filename)
msg := sprintf("Debug/test artifact detected in filename: %s", [pkg.filename])
}View policy on GitHub
Trigger Condition
The below filename contains "debug" and will match your Rego pattern:
pkg := input.v0["package"]
re_match(".*(debug|test|tmp).*", pkg.filename)Policy will trigger on these kind of examples:
debugpy-1.6.7...whl
pytest-...tar.gz
mylib-test-1.0.0.tar.gz
tmp-utils-0.1.0.whl When and How It's Triggered
Cloudsmith EPM allows users to easily match package filename metadata based on Regular Expression (RE) string matching patterns.
Once ready, download debugpy Python package and push it to Cloudsmith to cause the policy violation:
pip download --no-deps --dest . debugpy
&& cloudsmith push python acme-corporation/acme-repo-one debugpy-1.8.14-cp310-cp310-manylinux_2_5_x86_64.manylinux1_x86_64.manylinux_2_17_x86_64.manylinux2014_x86_64.whl -k "$CLOUDSMITH_API_KEY"Business value from this policy
Preventing debug builds from entering production has a clear business value: it safeguards the stability, security, and performance of your production environment. Debug, test, and temporary builds often include unoptimized code, verbose logging, or leftover experimental changes that were never intended for public release. If such artifacts slip into production, they can introduce vulnerabilities, degrade application performance, or leak sensitive internal details. By enforcing this policy at the ingestion point, organizations ensure that only production-ready packages make it downstream, reducing the risk of costly outages, data breaches, or compliance violations.
The use of Regular Expressions (RegEx) adds a powerful layer of flexibility to this control. With a single concise pattern, an organization can detect a wide variety of disallowed naming conventions, whether they follow strict standards or evolve over time. This enables extremely granular decision-making without hardcoding multiple rules for every possible variation. In practice, RegEx matching allows teams to adapt policy enforcement to the natural naming habits of developers, vendors, or CI/CD pipelines, ensuring that policy stays both effective and easy to maintain as the software ecosystem grows and changes. The result is a balance of automation and adaptability that keeps production repositories clean without slowing down the development process.