<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>idea Allow use of commit hash in download-times.json to assist automated builds in ArcGIS Experience Builder Ideas</title>
    <link>https://community.esri.com/t5/arcgis-experience-builder-ideas/allow-use-of-commit-hash-in-download-times-json-to/idi-p/1592184</link>
    <description>&lt;P&gt;As documented &lt;A href="https://developers.arcgis.com/experience-builder/guide/deployment-topics/#service-worker-cache" target="_blank" rel="noopener"&gt;ArcGIS Experience Builder | Deployment&lt;/A&gt; you can manually rename cdn/x to cdn/y and update a couple references to bust the service worker cache. Alternatively you can increment the value in download-times.json file as well.&lt;/P&gt;&lt;P&gt;However, for CI/CD scenarios this is a bit cumbersome. It would be helpful if we could supply a git commit hash to use as the cache busting id. Some non-exhaustive suggestions.&lt;/P&gt;&lt;OL&gt;&lt;LI&gt;Either allow non-numeric ids in download-times.json or provide another file to write the preferred id&lt;/LI&gt;&lt;LI&gt;Update app-download.js to accept another parameter, `cacheId: string` that specifies the id to use&lt;/LI&gt;&lt;/OL&gt;&lt;P&gt;With this in place more options are available to developers to assist busting cache in a repeatable way. Folks could use commit hash, commit tag, date format, a numeric sequence, or anything else suitable for their particular needs.&lt;/P&gt;&lt;P&gt;---&lt;/P&gt;&lt;P&gt;For anyone seeing this that needs a quick workaround for their CI, you can turn your git short hash into an unsigned integer and set that as they value in the download-times.json. The number will be incremented by 1 in the final output but this should work until there is official support for arbitrary strings of our making.&lt;/P&gt;&lt;P&gt;Here's an example in PowerShell&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;LI-CODE lang="c"&gt;Write-Host "Busting cache..."
$gitHash = git rev-parse --short HEAD
$numHash = [uint32]"0x$gitHash"
$numHash | Set-Content $downloadTimesJsonFile -Force&lt;/LI-CODE&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;</description>
    <pubDate>Thu, 06 Mar 2025 15:37:06 GMT</pubDate>
    <dc:creator>RyanTaylor</dc:creator>
    <dc:date>2025-03-06T15:37:06Z</dc:date>
    <item>
      <title>Allow use of commit hash in download-times.json to assist automated builds</title>
      <link>https://community.esri.com/t5/arcgis-experience-builder-ideas/allow-use-of-commit-hash-in-download-times-json-to/idi-p/1592184</link>
      <description>&lt;P&gt;As documented &lt;A href="https://developers.arcgis.com/experience-builder/guide/deployment-topics/#service-worker-cache" target="_blank" rel="noopener"&gt;ArcGIS Experience Builder | Deployment&lt;/A&gt; you can manually rename cdn/x to cdn/y and update a couple references to bust the service worker cache. Alternatively you can increment the value in download-times.json file as well.&lt;/P&gt;&lt;P&gt;However, for CI/CD scenarios this is a bit cumbersome. It would be helpful if we could supply a git commit hash to use as the cache busting id. Some non-exhaustive suggestions.&lt;/P&gt;&lt;OL&gt;&lt;LI&gt;Either allow non-numeric ids in download-times.json or provide another file to write the preferred id&lt;/LI&gt;&lt;LI&gt;Update app-download.js to accept another parameter, `cacheId: string` that specifies the id to use&lt;/LI&gt;&lt;/OL&gt;&lt;P&gt;With this in place more options are available to developers to assist busting cache in a repeatable way. Folks could use commit hash, commit tag, date format, a numeric sequence, or anything else suitable for their particular needs.&lt;/P&gt;&lt;P&gt;---&lt;/P&gt;&lt;P&gt;For anyone seeing this that needs a quick workaround for their CI, you can turn your git short hash into an unsigned integer and set that as they value in the download-times.json. The number will be incremented by 1 in the final output but this should work until there is official support for arbitrary strings of our making.&lt;/P&gt;&lt;P&gt;Here's an example in PowerShell&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;LI-CODE lang="c"&gt;Write-Host "Busting cache..."
$gitHash = git rev-parse --short HEAD
$numHash = [uint32]"0x$gitHash"
$numHash | Set-Content $downloadTimesJsonFile -Force&lt;/LI-CODE&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Thu, 06 Mar 2025 15:37:06 GMT</pubDate>
      <guid>https://community.esri.com/t5/arcgis-experience-builder-ideas/allow-use-of-commit-hash-in-download-times-json-to/idi-p/1592184</guid>
      <dc:creator>RyanTaylor</dc:creator>
      <dc:date>2025-03-06T15:37:06Z</dc:date>
    </item>
    <item>
      <title>Re: Allow use of commit hash in download-times.json to assist automated builds</title>
      <link>https://community.esri.com/t5/arcgis-experience-builder-ideas/allow-use-of-commit-hash-in-download-times-json-to/idc-p/1596720#M3835</link>
      <description>&lt;P&gt;I'm just now reading about CI/CD deployment, and I've seen two different ways that works.&lt;BR /&gt;&lt;BR /&gt;Often the same folder is cleared, then deployed to on the host.&amp;nbsp; &amp;nbsp;Some create a new folder per build name and repoint stuff (that seems tricky to me)&lt;BR /&gt;&lt;BR /&gt;I know with Custom Widgets things getting cached can be frustrating at times.&amp;nbsp; I think updating one of the settings in manifest.json might have a cache busting impact, but&amp;nbsp; I have yet to prove that changing the version of the widget in the manifest does it reliabiliy.&lt;/P&gt;</description>
      <pubDate>Tue, 18 Mar 2025 18:18:35 GMT</pubDate>
      <guid>https://community.esri.com/t5/arcgis-experience-builder-ideas/allow-use-of-commit-hash-in-download-times-json-to/idc-p/1596720#M3835</guid>
      <dc:creator>TimWestern</dc:creator>
      <dc:date>2025-03-18T18:18:35Z</dc:date>
    </item>
  </channel>
</rss>

