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.
\nThe GitHub Actions build summary documentation is the primary reference.
\nThe 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.
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.
\nDSE 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.
\nInspect 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.
\nReview 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.
\nPlan 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.
\nProposed 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.
\nIf 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.
\nSource review completed October 30, 2026. Recheck the official documentation and deployment-specific applicability before a production change.
\n", "content_text": "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.\nSource fact: documented behavior\nThe GitHub Actions build summary documentation is the primary reference.\nThe 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.\nWhat the source does not establish\nThis 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.\nApplicability questions\n\nWhich documented action version is the workflow using?\nDoes the owner want the summary, the record archive or both?\nWhat operational evidence must remain available after the job?\nWho approves the retention and access arrangement for other job outputs?\n\nDSE recommendation: approve two retention choices explicitly\nDSE 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.\nInspect 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.\nReview 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.\nPlan 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.\nVerification and evidence\nProposed 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.\nIf 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.\nOfficial references\n\nGitHub Actions build summary — Docker Docs.\n\nSource review completed October 30, 2026. Recheck the official documentation and deployment-specific applicability before a production change.", "content_markdown": "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.\n\n## Source fact: documented behavior\n\nThe [GitHub Actions build summary](https://docs.docker.com/build/ci/github-actions/build-summary/) documentation is the primary reference.\n\nThe 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.\n\n## What the source does not establish\n\nThis 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.\n\n## Applicability questions\n\n- Which documented action version is the workflow using?\n\n- Does the owner want the summary, the record archive or both?\n\n- What operational evidence must remain available after the job?\n\n- Who approves the retention and access arrangement for other job outputs?\n\n## DSE recommendation: approve two retention choices explicitly\n\nDSE 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.\n\nInspect 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.\n\nReview 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.\n\nPlan 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.\n\n## Verification and evidence\n\nProposed 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.\n\nIf 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.\n\n## Official references\n\n- [GitHub Actions build summary](https://docs.docker.com/build/ci/github-actions/build-summary/) — Docker Docs.\n\nSource review completed October 30, 2026. Recheck the official documentation and deployment-specific applicability before a production change." }, "json_ld": { "@context": "https://schema.org", "@graph": [ { "@type": "Organization", "@id": "https://dsesecurity.com/#organization", "name": "Detection Systems & Engineering", "alternateName": "DSE Security", "url": "https://dsesecurity.com/", "logo": { "@type": "ImageObject", "url": "https://update.dsesecurity.com/assets/dse-logo-20260812.png?v=1.8.20" } }, { "@type": "Organization", "@id": "https://update.dsesecurity.com/#editorial-team", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/", "parentOrganization": { "@id": "https://dsesecurity.com/#organization" } }, { "@type": "WebSite", "@id": "https://update.dsesecurity.com/#website", "name": "DSE Updates", "alternateName": "DSE Security Knowledge Hub", "url": "https://update.dsesecurity.com/", "inLanguage": "en-US", "publisher": { "@id": "https://dsesecurity.com/#organization" }, "potentialAction": { "@type": "SearchAction", "target": { "@type": "EntryPoint", "urlTemplate": "https://update.dsesecurity.com/?q={search_term_string}" }, "query-input": "required name=search_term_string" } }, { "@type": "WebPage", "@id": "https://update.dsesecurity.com/updates/disable-docker-build-record-upload-without-disabling-the-job-summary/", "url": "https://update.dsesecurity.com/updates/disable-docker-build-record-upload-without-disabling-the-job-summary/", "isPartOf": { "@id": "https://update.dsesecurity.com/#website" }, "lastReviewed": "2026-10-30" }, { "@type": "BreadcrumbList", "@id": "https://update.dsesecurity.com/updates/disable-docker-build-record-upload-without-disabling-the-job-summary/#breadcrumbs", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "DSE Updates", "item": "https://update.dsesecurity.com/" }, { "@type": "ListItem", "position": 2, "name": "Cybersecurity", "item": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "@type": "ListItem", "position": 3, "name": "Disable Docker build-record upload without disabling the job summary", "item": "https://update.dsesecurity.com/updates/disable-docker-build-record-upload-without-disabling-the-job-summary/" } ] }, { "@type": [ "Article", "TechArticle" ], "@id": "https://update.dsesecurity.com/updates/disable-docker-build-record-upload-without-disabling-the-job-summary/#article", "identifier": "https://update.dsesecurity.com/updates/disable-docker-build-record-upload-without-disabling-the-job-summary/", "url": "https://update.dsesecurity.com/updates/disable-docker-build-record-upload-without-disabling-the-job-summary/", "headline": "Disable Docker build-record upload without disabling the job summary", "description": "Use the distinct Docker GitHub Actions controls for summary generation and build-record archive upload when deciding what a job should retain.", "abstract": "Use the distinct Docker GitHub Actions controls for summary generation and build-record archive upload when deciding what a job should retain.", "articleBody": "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.\nSource fact: documented behavior\nThe GitHub Actions build summary documentation is the primary reference.\nThe 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.\nWhat the source does not establish\nThis 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.\nApplicability questions\n\nWhich documented action version is the workflow using?\nDoes the owner want the summary, the record archive or both?\nWhat operational evidence must remain available after the job?\nWho approves the retention and access arrangement for other job outputs?\n\nDSE recommendation: approve two retention choices explicitly\nDSE 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.\nInspect 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.\nReview 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.\nPlan 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.\nVerification and evidence\nProposed 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.\nIf 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.\nOfficial references\n\nGitHub Actions build summary — Docker Docs.\n\nSource review completed October 30, 2026. Recheck the official documentation and deployment-specific applicability before a production change.", "datePublished": "2026-10-30T06:46:42+00:00", "dateModified": "2026-10-30T06:47:30+00:00", "mainEntityOfPage": { "@id": "https://update.dsesecurity.com/updates/disable-docker-build-record-upload-without-disabling-the-job-summary/" }, "inLanguage": "en-US", "isAccessibleForFree": true, "author": { "@type": "Organization", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team" }, "publisher": { "@id": "https://dsesecurity.com/#organization" }, "image": { "@type": "ImageObject", "@id": "https://update.dsesecurity.com/updates/disable-docker-build-record-upload-without-disabling-the-job-summary/#primaryimage", "url": "https://update.dsesecurity.com/assets/editorial/cyber-defense-social-v2.jpg?v=1.8.20", "contentUrl": "https://update.dsesecurity.com/assets/editorial/cyber-defense-social-v2.jpg?v=1.8.20", "width": 1200, "height": 630, "caption": "Disable Docker build-record upload without disabling the job summary" }, "articleSection": [ "Cybersecurity", "IT" ], "keywords": [ "Cybersecurity", "IT", "Guide", "Advisory priority" ], "genre": "Guide", "about": [ { "@type": "Thing", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "@type": "Thing", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" } ], "wordCount": 499, "timeRequired": "PT3M", "publishingPrinciples": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usageInfo": "https://update.dsesecurity.com/usage/", "copyrightHolder": { "@id": "https://dsesecurity.com/#organization" }, "copyrightNotice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "citation": { "@type": "CreativeWork", "name": "Docker Docs — GitHub Actions build summary", "url": "https://docs.docker.com/build/ci/github-actions/build-summary/" } } ] } }