feat: support setting custom_resource_build_prefix via environment variable

[tmeckel]

Community Note

Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request.
Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request.
If you are interested in working on this issue or have submitted a pull request, please leave a comment.

Description

The azure-arm builder supports the custom_resource_build_prefix property, which is invaluable for identifying and managing resources created by Packer. However, this setting can only be configured within the Packer template (HCL/JSON). This limitation introduces significant challenges in automated CI/CD environments where reliable resource cleanup is critical.
In a pipeline-driven workflow, cleanup logic often runs as a separate, guaranteed step (e.g., a post-run stage) to remove orphaned resources, especially if a build is canceled or fails unexpectedly. The reliability of this cleanup process depends on a consistent and predictable naming scheme for temporary resources.

Use Case(s)

Relying solely on a setting that every developer must manually add to every Packer template makes the cleanup process inherently brittle. The responsibility for enforcing a resource naming convention is shifted to individual practitioners, leading to several potential failure points:

• Human Error: A user might forget to add the custom_resource_build_prefix to a new image template or accidentally delete it from an existing one. The build would still run, but the created resources would lack the necessary prefix, evading the automated cleanup script and becoming orphaned.

• Inconsistent Naming: In a large organization, different teams might adopt slightly different prefixes or naming conventions. A centralized cleanup script cannot reliably target resources if there isn't a single, enforceable standard.

• Failed or Canceled Pipelines: Consider a scenario where a pipeline is manually canceled or fails due to an external factor (e.g., a network issue while Packer is provisioning the VM). The main Packer process is terminated, but the Azure resources it created remain. A subsequent cleanup job must be able to identify these resources. Without a guaranteed prefix, the cleanup script would have no reliable way to distinguish Packer-generated temporary resources from other important assets in the resource group.

These scenarios lead to orphaned resources, which incur unnecessary costs and create clutter in the Azure subscription, complicating resource management and auditing.

Potential configuration

To significantly improve the robustness of automated workflows, we propose introducing an environment variable to serve as a fallback or default for the custom_resource_build_prefix.

For example:
PACKER_AZURE_CUSTOM_RESOURCE_BUILD_PREFIX

The order of precedence would be:

1. custom_resource_build_prefix set explicitly in the builder configuration (HCL/JSON).
2. PACKER_AZURE_CUSTOM_RESOURCE_BUILD_PREFIX environment variable, if the template property is not set.

Benefits

• Centralized and Enforceable Naming: The CI/CD system can set the environment variable at the pipeline level, guaranteeing that all Packer builds initiated by the pipeline adhere to a consistent naming convention without any action required from the user.

• Increased Reliability: Cleanup scripts can be written to confidently target a known prefix, making them far more reliable in catching orphaned resources from failed or canceled builds.

• Reduced Cognitive Load: Practitioners no longer need to remember to add this specific setting to every template, allowing them to focus on the image configuration itself.

• Maintained Flexibility: By allowing the in-template setting to override the environment variable, advanced users retain the flexibility to specify a different prefix for special cases if needed.