Disable Docker build-record upload without disabling the job summary

Bottom line: Write down whether the workflow should keep its job summary, its downloadable build record or both. Review the two controls separately so a retention decision does not accidentally remove the intended operational summary.

Source fact: documented behavior

The GitHub Actions build summary documentation is the primary reference.

The guide documents automatic summaries for docker/build-push-action@v7 and docker/bake-action@v7. Setting DOCKER_BUILD_SUMMARY to false disables the job summary. Setting DOCKER_BUILD_RECORD_UPLOAD to false suppresses the build-record archive upload while leaving a summary without its download link.

What the source does not establish

This article covers the documented GitHub.com build-summary workflow and its named controls. It does not describe every artifact-download action, prove that no other job data is retained or supply a comprehensive confidentiality policy. Keep cache publication, ordinary application artifacts and workflow secrets under their separate controls.

Applicability questions

• Which documented action version is the workflow using?
• Does the owner want the summary, the record archive or both?
• What operational evidence must remain available after the job?
• Who approves the retention and access arrangement for other job outputs?

DSE recommendation: approve two retention choices explicitly

DSE recommends a small decision table with separate columns for summary generation and build-record upload. Have the workflow owner mark the required state of each. Keep the reason tied to actual operational needs instead of treating a single on/off choice as a policy for every build output.

Inspect the managed workflow where the selected action receives its environment. Record the exact control names and proposed values without adding unrelated environment changes. Require a reviewer to explain which visible result should remain and which link or archive should be absent.

Review ordinary application artifacts independently. Identify the release deliverable and its own upload or download step, and leave its retention decision outside this change unless separately authorized. Do not introduce an artifact-name exclusion pattern based on assumptions that this source does not document.

Plan how a failed job will be investigated under the chosen arrangement. Ask the build owner which retained observations are necessary and whether the summary alone meets that requirement. Keep an approved route for obtaining additional diagnostic evidence without silently restoring every upload or copying sensitive inputs into a ticket.

Verification and evidence

Proposed verification: prepare a harmless GitHub.com test workflow using a documented action version. Run an approved baseline with both features enabled, then a separate case with only record upload disabled. Predict the summary and download-link observations before comparing the actual job pages.

If disabling the summary is also proposed, exercise that as a third isolated case. Retain the sanitized workflow revision and actual visible results for each configuration. Check the application artifact through its own acceptance step. Report only what was observed; absence of this archive is not evidence that the entire workflow retained no data.

Official references

• GitHub Actions build summary — Docker Docs.

Source review completed October 30, 2026. Recheck the official documentation and deployment-specific applicability before a production change.