--- title: DRY isn't just for application code | daily.dev description: Octopus Deploy consolidated twenty duplicated GitHub Actions workflow files across five microsite repositories into a single set of reusable workflows called... canonical: https://daily.dev/posts/dry-isn-t-just-for-application-code-tqbsmydfp twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: DRY isn't just for application code | daily.dev og:description: Octopus Deploy consolidated twenty duplicated GitHub Actions workflow files across five microsite repositories into a single set of reusable workflows called... og:url: https://daily.dev/posts/dry-isn-t-just-for-application-code-tqbsmydfp og:image: https://api.daily.dev/og/posts/TQBSmydfP.png og:image:alt: DRY isn't just for application code og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # DRY isn't just for application code **[OctopusDeploy](https://daily.dev/sources/octopusdeploy)** · 16 min read · 0 upvotes · 0 comments ## Summary Octopus Deploy consolidated twenty duplicated GitHub Actions workflow files across five microsite repositories into a single set of reusable workflows called from a central repository. A change that once meant five pull requests now needs just one. The team chose to reference workflows with the floating '@main' branch rather than tags or SHAs, accepting that any bad change hits every consumer immediately. They note GitHub offers no built-in way to version workflows independently within one repo, no visibility into who calls a workflow or which version they use, and that blocking old versions via the allowed-actions policy is a hard stop with no grace period. Dependabot can raise update PRs but each consumer still decides when to merge. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### Should I reference a reusable GitHub Actions workflow with @main, a tag, or a commit SHA? Each has a tradeoff: '@main' is a floating reference so every caller gets changes immediately but risks breaking everyone at once; a tag like '@v1.2.0' is more predictable but tags are mutable unless you use GitHub's immutable releases; a commit SHA is the most stable since it always points to the exact same code, though a 40-character hash is unreadable without a comment noting the version. _Weighing workflow versioning tradeoffs is easier when daily.dev surfaces how other platform teams handle CI/CD governance._ ### Can I version individual reusable workflows separately within the same GitHub repository? No, there is no built-in way to version reusable workflows independently within one repository, because a Git tag points to a commit and that commit covers every workflow file in the repo. Tagging a change to one workflow 'v1.3.0' means a consumer of a different, unchanged workflow who moves to that tag still picks up that commit's state. Workarounds include prefixed tags, splitting workflows into separate repositories, or community tools like the Workflow Independent Release Engine. _Developers untangling shared CI workflow versioning can track similar platform engineering patterns through daily.dev._ ### Can GitHub force teams to stop using an outdated reusable workflow version? Yes, administrators can use the allowed actions and reusable workflows policy to block a specific version by adding it with a '!' prefix, and blocks override anything else the policy allows. However, it's a hard stop with no warning phase or grace period: the next run on a blocked version simply fails, since GitHub built this for supply chain security rather than for managing internal workflow lifecycle rollouts. _Teams planning safe rollouts of internal tooling changes can follow platform engineering governance discussions on daily.dev._ ## Similar posts on daily.dev - [From copy-paste to platform thinking](https://daily.dev/posts/from-copy-paste-to-platform-thinking-1ldqhritr) · OctopusDeploy · 0 upvotes · 0 comments - [Pushing to main still needs a process](https://daily.dev/posts/pushing-to-main-still-needs-a-process-8fiuv9qrn) · Flavio Copes · 0 upvotes · 0 comments - [GitHub Actions workflow lockfiles in public preview](https://daily.dev/posts/github-actions-workflow-lockfiles-in-public-preview-3zoik06ky) · GitHub Changelog · 0 upvotes · 0 comments - [Never Review a Dependency Update Again](https://daily.dev/posts/never-review-a-dependency-update-again-zyvszt5gf) · TypeScript.TV · 1 upvotes · 0 comments --- Tags: [#cicd](https://daily.dev/tags/cicd), [#github-actions](https://daily.dev/tags/github-actions), [#platform-engineering](https://daily.dev/tags/platform-engineering), [#dependabot](https://daily.dev/tags/dependabot) [View this post on daily.dev](https://daily.dev/posts/dry-isn-t-just-for-application-code-tqbsmydfp) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"DRY isn't just for application code","url":"https://daily.dev/posts/dry-isn-t-just-for-application-code-tqbsmydfp","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/dry-isn-t-just-for-application-code-tqbsmydfp"},"datePublished":"2026-10-28T12:03:49.399Z","dateModified":"2026-10-28T14:58:29.914Z","description":"Octopus Deploy consolidated twenty duplicated GitHub Actions workflow files across five microsite repositories into a single set of reusable workflows called...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/5a4db535c82fec7677e10044939d3094?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/5a4db535c82fec7677e10044939d3094?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"OctopusDeploy","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"OctopusDeploy","logo":"https://media.daily.dev/image/upload/t_logo,f_auto/v1/logos/71110ae886d64eac9f3a01496feb2bd8","url":"https://daily.dev/sources/octopusdeploy"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/dry-isn-t-just-for-application-code-tqbsmydfp","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":0},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"cicd,github-actions,platform-engineering,dependabot","timeRequired":"PT16M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"OctopusDeploy","item":"https://daily.dev/sources/octopusdeploy"},{"@type":"ListItem","position":3,"name":"DRY isn't just for application code"}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/dry-isn-t-just-for-application-code-tqbsmydfp#faq","mainEntity":[{"@type":"Question","name":"Should I reference a reusable GitHub Actions workflow with @main, a tag, or a commit SHA?","acceptedAnswer":{"@type":"Answer","text":"Each has a tradeoff: '@main' is a floating reference so every caller gets changes immediately but risks breaking everyone at once; a tag like '@v1.2.0' is more predictable but tags are mutable unless you use GitHub's immutable releases; a commit SHA is the most stable since it always points to the exact same code, though a 40-character hash is unreadable without a comment noting the version. Weighing workflow versioning tradeoffs is easier when daily.dev surfaces how other platform teams handle CI/CD governance."}},{"@type":"Question","name":"Can I version individual reusable workflows separately within the same GitHub repository?","acceptedAnswer":{"@type":"Answer","text":"No, there is no built-in way to version reusable workflows independently within one repository, because a Git tag points to a commit and that commit covers every workflow file in the repo. Tagging a change to one workflow 'v1.3.0' means a consumer of a different, unchanged workflow who moves to that tag still picks up that commit's state. Workarounds include prefixed tags, splitting workflows into separate repositories, or community tools like the Workflow Independent Release Engine. Developers untangling shared CI workflow versioning can track similar platform engineering patterns through daily.dev."}},{"@type":"Question","name":"Can GitHub force teams to stop using an outdated reusable workflow version?","acceptedAnswer":{"@type":"Answer","text":"Yes, administrators can use the allowed actions and reusable workflows policy to block a specific version by adding it with a '!' prefix, and blocks override anything else the policy allows. However, it's a hard stop with no warning phase or grace period: the next run on a blocked version simply fails, since GitHub built this for supply chain security rather than for managing internal workflow lifecycle rollouts. Teams planning safe rollouts of internal tooling changes can follow platform engineering governance discussions on daily.dev."}}]} ```