
  <rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
    <channel>
      <title>Johnny - Notes</title>
      <link>https://johnnyhuy.com/notes</link>
      <description>Short, self-contained, actionable write-ups. Each note is something a reader could act on, or would otherwise have to rediscover.</description>
      <language>en</language>
      <managingEditor> (Johnny Huynh)</managingEditor>
      <webMaster> (Johnny Huynh)</webMaster>
      <lastBuildDate>Fri, 11 Sep 2026 22:05:00 GMT</lastBuildDate>
      <atom:link href="https://johnnyhuy.com/notes/feed.xml" rel="self" type="application/rss+xml"/>
      
  <item>
    <guid>https://johnnyhuy.com/notes/terraform-plan-is-not-drift-detection</guid>
    <title>Terraform Plan Is Not Drift Detection</title>
    <link>https://johnnyhuy.com/notes/terraform-plan-is-not-drift-detection</link>
    <description>A plan on a schedule detects pending configuration changes. It does not detect drift, because drift is unrecorded change to live infrastructure and a plan has no way to see it unless you ask for a refresh-only run. It also exits 0 with real differences present. Two facts, and most homegrown drift detection is wrong because it missed one of them.
</description>
    <pubDate>Fri, 11 Sep 2026 22:05:00 GMT</pubDate>
    <author> (Johnny Huynh)</author>
    <category>Terraform</category><category>Infrastructure as Code</category><category>Drift Detection</category>
  </item>

  <item>
    <guid>https://johnnyhuy.com/notes/github-token-suppresses-pull-request-ci</guid>
    <title>GitHub Actions Silently Skips CI on PRs Opened by GITHUB_TOKEN</title>
    <link>https://johnnyhuy.com/notes/github-token-suppresses-pull-request-ci</link>
    <description>GitHub does not run pull_request workflows for pull requests that GITHUB_TOKEN opened. Any release tool that opens its own PR (release-please, semantic-release, changesets, Mergify) will therefore never see its own release PR pass CI. Nothing errors, nothing is annotated, the checks just do not exist. Here is the rule, how to prove you have hit it, and the three ways out.
</description>
    <pubDate>Sat, 29 Aug 2026 23:20:00 GMT</pubDate>
    <author> (Johnny Huynh)</author>
    <category>CI/CD</category><category>GitHub Actions</category><category>Release Automation</category>
  </item>

  <item>
    <guid>https://johnnyhuy.com/notes/helm-does-not-install-crds-on-upgrade</guid>
    <title>Helm Does Not Install CRDs on Upgrade</title>
    <link>https://johnnyhuy.com/notes/helm-does-not-install-crds-on-upgrade</link>
    <description>CRDs in a chart&#39;s crds/ directory are only applied by helm install. helm upgrade skips them entirely, with no warning. If your External Secrets Operator ClusterSecretStore or your cert-manager Issuer disappears, this is why, and the fix is not in your values file because the values file is never read.
</description>
    <pubDate>Wed, 22 Jul 2026 04:10:00 GMT</pubDate>
    <author> (Johnny Huynh)</author>
    <category>Kubernetes</category><category>Helm</category><category>External Secrets Operator</category>
  </item>

  <item>
    <guid>https://johnnyhuy.com/notes/cold-coresimulator-hangs-on-fresh-runners</guid>
    <title>Cold CoreSimulator Hangs on Fresh macOS Runners</title>
    <link>https://johnnyhuy.com/notes/cold-coresimulator-hangs-on-fresh-runners</link>
    <description>On a fresh GitHub Actions macOS runner, the first iOS simulator boot can hang indefinitely with no output. The job does not fail, it just stops making progress until timeout-minutes kills it. Shutting down and erasing the prewarmed simulators before the first boot is the fix, and bootstatus instead of sleep is what turns an invisible hang into a readable failure.
</description>
    <pubDate>Sun, 14 Jun 2026 01:45:00 GMT</pubDate>
    <author> (Johnny Huynh)</author>
    <category>CI/CD</category><category>iOS</category><category>Testing</category>
  </item>

    </channel>
  </rss>
