[Bug]: Pull Request Handler redownloads artifacts to compiler folder despite using explicit, static artifact URL

[cegekaJG]

AL-Go version

6.0

Describe the issue

Since several of our projects are OnPrem for a single environment, we explicitly define artifact URLs when possible for our AL Go projects. However, despite the fact that the BC artifact therefore never changes, roughly 20% of all runs of the action "Pull Request Handler" will still take significantly longer setting up the compiler folder, effectively doubling the runtime of the workflow.

Expected behavior

The workflow should have similar runtimes.
If there is something like a timer to an automatic reset of the complier folder, there should be a way to either circumvent this or trigger it in a separate workflow to keep runtimes consistent, as they otherwise take too long for some time-sensitive tasks.

Steps to reproduce

Here are my settings:

.AL-Go/settings.json

{
  "$schema": "https://raw.githubusercontent.com/microsoft/AL-Go/v5.1/Schema/algosettingssyntax.json",
  "artifact": "https://bcartifacts-exdbf9fwegejdqak.b02.azurefd.net/sandbox/25.1.25873.26735/at",
  "country": "at",
  "generateDependencyArtifact": true
}

.github/AL-Go-Settings.json

{
  "$schema": "https://raw.githubusercontent.com/microsoft/AL-Go/v5.1/Schema/algoreposettingssyntax.json",
  "buildModes": [
    "Default"
  ],
  "customCodeCops": [
    "https://github.com/StefanMaron/BusinessCentral.LinterCop/releases/latest/download/BusinessCentral.LinterCop.current.dll"
  ],
  "doNotPublishApps": true,
  "enableCodeCop": true,
  "enableExternalRulesets": true,
  "enablePerTenantExtensionCop": false,
  "enableUICop": true,
  "githubRunner": "ubuntu-latest",
  "runs-on": "ubuntu-latest",
  "skipUpgrade": true,
  "templateUrl": "https://github.com/CBS-BC-AT/AL-Go@cegeka6",
  "templateFiles": [
    ".github/DeployTo*.ps1",
    ".schemas/*"
  ],
  "type": "PTE",
  "UpdateGitHubGoSystemFilesSchedule": "0 2 * * 1",
  "useCompilerFolder": true,
  "vsixFile": "latest"
}

To reproduce, starting multiple status checks of a pull request in a repo using these settings would be required. I have yet to find any pattern on which runs will take longer to complete, or even if it only applies to certain pull requests.

Additional context (logs, screenshots, etc.)

Run with normal execution time

Run with slow execution time

[freddydk]

It looks like we are hitting the download limit on the bcartifacts - which says maximum 1000 downloads per minut.
I have increased the limit to 5000 - lets see if this still happens.