<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Github Actions on rmqa.com</title>
    <link>https://rmqa.com/tags/github-actions/</link>
    <description>Recent content in Github Actions on rmqa.com</description>
    <generator>Hugo</generator>
    <language>en-us</language>
    <lastBuildDate>Sun, 25 Oct 2026 00:00:00 +0000</lastBuildDate>
    <atom:link href="https://rmqa.com/tags/github-actions/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Wrong Build in the arm64 Archive Caught Before a Go CLI Release Went Out</title>
      <link>https://rmqa.com/wrong-build-in-the-arm64-archive-caught-before-a-go-cli-release-went-out/</link>
      <pubDate>Sun, 25 Oct 2026 00:00:00 +0000</pubDate>
      <guid>https://rmqa.com/wrong-build-in-the-arm64-archive-caught-before-a-go-cli-release-went-out/</guid>
      <description>&lt;p&gt;Say a small team maintains a command-line tool in Go called &lt;code&gt;tidy&lt;/code&gt;. Each release ships five archives, for Linux on Intel and ARM, macOS on Apple silicon and Intel, and Windows, plus a &lt;code&gt;SHA256SUMS&lt;/code&gt; file. A release workflow builds them in a matrix of jobs and a final job uploads everything.&lt;/p&gt;&#xA;&lt;p&gt;One day a refactor of the workflow moves the build output into a shared folder. The Linux ARM job now packs whatever &lt;code&gt;tidy&lt;/code&gt; binary is in that folder, and on the runner where it lands, that&amp;rsquo;s the Intel build. Meanwhile the Intel Mac job hits a cache from the previous release and doesn&amp;rsquo;t rebuild. Every job is green. The archives have the right names and plausible sizes.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
