[Bug]: Pull Request Build - The directory is not empty. (Flush ContainerHelper Cache)

[fvet]

AL-Go version

8.1

Describe the issue

When the Pull Request Build action is ran, the Flush ContainerHelper Cache part of the Build step fails

Flush ContainerHelper Cache
  Removing C:\bcartifacts.cache\sandbox\27.3.44313.44979\platform
  Flush-ContainerHelperCache Telemetry Correlation Id: cee4ac57-369c-41ab-9da3-5a5be8e5f752
  Test-BcContainer Telemetry Correlation Id: 33afe1cb-c321-41fd-b1bf-4aace517a634
  Enabling Microsoft telemetry...
  Enabling partner telemetry...
  Error: Unexpected error when running action. Error Message: The directory is not empty. : 'C:\bcartifacts.cache\sandbox\27.3.44313.44979\platform\applications\Email - Current User Connector'., StackTrace: at <ScriptBlock>, C:\ProgramData\BcContainerHelper\6.1.10\BcContainerHelper\ContainerHandling\Flush-ContainerHelperCache.ps1: line 123 <- at <ScriptBlock>, C:\ProgramData\BcContainerHelper\6.1.10\BcContainerHelper\ContainerHandling\Flush-ContainerHelperCache.ps1: line 116 <- at <ScriptBlock>, C:\ProgramData\BcContainerHelper\6.1.10\BcContainerHelper\ContainerHandling\Flush-ContainerHelperCache.ps1: line 114 <- at Flush-ContainerHelperCache, C:\ProgramData\BcContainerHelper\6.1.10\BcContainerHelper\ContainerHandling\Flush-ContainerHelperCache.ps1: line 112 <- at <ScriptBlock>, C:\Github\actions-runner-4\_work\_actions\microsoft\AL-Go-Actions\v8.1\RunPipeline\RunPipeline.ps1: line 278 <- at <ScriptBlock>, C:\Github\actions-runner-4\_work\_temp\e2ca574a-4e56-4d6a-9a58-da8293364ddd.ps1: line 3 <- at <ScriptBlock>, C:\Github\actions-runner-4\_work\_actions\microsoft\AL-Go-Actions\v8.1\Invoke-AlGoAction.ps1: line 21 <- at <ScriptBlock>, C:\Github\actions-runner-4\_work\_temp\e2ca574a-4e56-4d6a-9a58-da8293364ddd.ps1: line 2 <- at <ScriptBlock>, <No file>: line 1
  Error: Process completed with exit code 1.

Here's the overview of the Last Used files in the bcartifacts.cache folder...

... and the remaining content of the folders to be deleted.

Our current setup is:

• Self-hosted build server with several build agents for Azure Devops pipelines
• Same build server with several github runners for Github actions
• Shared C:\bcartifacts.cache folders

As we're gradually moving away from Azure Devops to Github and want to avoid having to buy a new build server, the current build server is - temporarily - used to host both Azure Devops build agents and Github runners. Both are using the same C:\bcartifacts.cache I suppose (default config)

Although no agents seems to be running / locking files from C:\bcartifacts.cache, the Flush ContainerHelper Cache step is not able to delete (locked?) files. Logging on to the server and deleting folder content manually solves the issue.

Expected behavior

• (Config) Are there any work-around / settings to have Github runner use C:\bcartifacts.cache from a different location? (not interfering with the same bcartifacts.cache used by bccontainerhelper from Azure Devops agents?)
• (Fix) Is it possible to continue the Build step if the Flush ContainerHelper Cache* step would have failed for any reason?

Steps to reproduce

x

Additional context (logs, screenshots, etc.)

logs_55425237442 (1).zip

[aholstrup1]

(Config) Are there any work-around / settings to have Github runner use C:\bcartifacts.cache from a different location? (not interfering with the same bcartifacts.cache used by bccontainerhelper from Azure Devops agents?)

I think normally you should be able to update the bccontainerHelperConfig settings from your AL-Go settings files. You could try creating a setting called bcartifactsCacheFolder and set it to "c:\bcartifacts.githubcache" for example.

[fvet]

@aholstrup1 Thanks for the hint!

I'll add this setting and keep an eye on it and will close the issue if fixed.

PS/ Could be interesting mentioning the use of 'bccontainerHelperConfig' settings in the AL-Go settings?
https://github.com/microsoft/AL-Go/blob/main/Scenarios/settings.md

---

For my reference:

"bcartifactsCacheFolder": "F:\\bcartifacts.cache",

[freddydk]

It is mentioned under point 3 here:

https://github.com/microsoft/AL-Go/blob/main/Scenarios/settings.md#where-are-the-settings-located

Could obviously have been more detailed about what this means:-)

[aholstrup1]

Did this mitigate your issue @fvet ?

[dsaveyn]

@aholstrup1 Unfortunately the issue still occurs after the changes @fvet did. ALOps now has one artifacts folder (f:\alops.bcartifacts.cache) and AL-Go another (f:\bcartifacts.cache).

I just got the error when performing a CI/CD run using Al-Go:

Full log:

Run microsoft/AL-Go-Actions/RunPipeline@v8.2 Run F:\Github\actions-runner-3\_work\_actions\microsoft\AL-Go-Actions\v8.2\RunPipeline/../Invoke-AlGoAction.ps1 -ActionName "RunPipeline" -Action { Import from C:\ProgramData\BcContainerHelper\6.1.11\BcContainerHelper\BcContainerHelper.ps1 BcContainerHelper version 6.1.11 Setting useCompilerFolder = True Setting PartnerTelemetryConnectionString = InstrumentationKey=1ac2e39d-c00c-487a-9fc0-e368fe6d9b24;IngestionEndpoint=https://westeurope-5.in.applicationinsights.azure.com/;LiveEndpoint=https://westeurope.livediagnostics.monitor.azure.com/;ApplicationId=5fa37872-b1f8-4849-a80e-79a76e555b9e Ignoring unchanged config setting SendExtendedTelemetryToMicrosoft Setting MicrosoftTelemetryConnectionString = InstrumentationKey=cd2cc63e-0f37-4968-b99a-532411a314b8;IngestionEndpoint=https://northeurope-2.in.applicationinsights.azure.com/ Setting bcartifactsCacheFolder = F:\bcartifacts.cache BC.HelperFunctions emits usage statistics telemetry to Microsoft Running on Windows, PowerShell 7.5.4 Get-BestGenericImageName Telemetry Correlation Id: 29e8d0ef-6494-4510-bf7e-58869193b2ce use settings and secrets Checking type Checking appFolders, testFolders and bcptTestFolders Application Dependency 25.0.0.0 Checking artifact setting for project Downloading artifacts from https://bcartifacts-exdbf9fwegejdqak.b02.azurefd.net/sandbox/25.0.23364.42373/us Download-Artifacts Telemetry Correlation Id: 4f31ef80-7b00-4de1-ac1e-b3f34d149645 Updating app- and test Dependencies Analyzing Test App Dependencies No performance test apps found in bcptTestFolders in .AL-Go\settings.json Warning: No test apps found in testFolders in .AL-Go\settings.json Checking appDependencyProbingPaths Reading TrustedNuGetFeeds Locating previous release Flush ContainerHelper Cache Removing F:\bcartifacts.cache\sandbox\25.0.23364.42082\be Removing F:\bcartifacts.cache\sandbox\25.0.23364.42082\nl Removing F:\bcartifacts.cache\sandbox\25.0.23364.42082\platform Flush-ContainerHelperCache Telemetry Correlation Id: e7f49ca4-8426-4a8f-ab36-4422174a66f0 Test-BcContainer Telemetry Correlation Id: 96956bcd-cb12-4207-bd9a-e675de859404 Enabling Microsoft telemetry... Enabling partner telemetry... Error: Unexpected error when running action. Error Message: The directory is not empty. : 'F:\bcartifacts.cache\sandbox\25.0.23364.42082\platform\applications\APIV1'., StackTrace: at <ScriptBlock>, C:\ProgramData\BcContainerHelper\6.1.11\BcContainerHelper\ContainerHandling\Flush-ContainerHelperCache.ps1: line 123 <- at <ScriptBlock>, C:\ProgramData\BcContainerHelper\6.1.11\BcContainerHelper\ContainerHandling\Flush-ContainerHelperCache.ps1: line 116 <- at <ScriptBlock>, C:\ProgramData\BcContainerHelper\6.1.11\BcContainerHelper\ContainerHandling\Flush-ContainerHelperCache.ps1: line 114 <- at Flush-ContainerHelperCache, C:\ProgramData\BcContainerHelper\6.1.11\BcContainerHelper\ContainerHandling\Flush-ContainerHelperCache.ps1: line 112 <- at <ScriptBlock>, F:\Github\actions-runner-3\_work\_actions\microsoft\AL-Go-Actions\v8.2\RunPipeline\RunPipeline.ps1: line 309 <- at <ScriptBlock>, F:\Github\actions-runner-3\_work\_temp\9c052337-c406-4f66-847f-6094326de039.ps1: line 3 <- at <ScriptBlock>, F:\Github\actions-runner-3\_work\_actions\microsoft\AL-Go-Actions\v8.2\Invoke-AlGoAction.ps1: line 21 <- at <ScriptBlock>, F:\Github\actions-runner-3\_work\_temp\9c052337-c406-4f66-847f-6094326de039.ps1: line 2 <- at <ScriptBlock>, <No file>: line 1 Error: Process completed with exit code 1.

I double checked the config to make sure ALOps was not using the directory, but it wasn't. Any ideas?

[SvenPouwelsBli]

We're experiencing the same issue. It seems to have something to do with the folders being set to read-only on disk. If we manually remove the read-only status from the folders (and the files within those folders) and run the pipeline again, it is able to remove the files as intended.