[Bug]: CI/CD build can fail in `Publish artifacts - apps` when `actions/upload-artifact` exits without an error message

[SchulzOli]

AL-Go version

9.0

Describe the issue

We are seeing intermittent CI/CD failures in an AL-Go generated build workflow during the Publish artifacts - apps step.

The AL build and signing steps complete successfully. The failing step is the AL-Go generated artifact upload for the Apps artifact:

uses: actions/upload-artifact@bbbca2ddaa5d8feaa63e36b76fdaad77386f024f # v7.0.0
with:
  name: FashionDemo-main-Apps-28.0.204730.0
  path: FashionDemo/.buildartifacts/Apps/
  if-no-files-found: ignore
  retention-days: 0
  compression-level: 6
  overwrite: false
  include-hidden-files: false
  archive: true

The step output ends after validation, without a useful error message:

With the provided path, there will be 1 file uploaded
Artifact name is valid!
Root directory input is valid!

There is no Uploading artifact: ... line and no visible ##[error]... message. The job continues to later if: success() || failure() steps, and the Publish artifacts - build output step succeeds immediately afterwards.

This makes the failure look like an actions/upload-artifact service/client failure that is exposed by the generated AL-Go workflow, not like an AL compiler or signing failure.

Expected behavior

If the AL app has been compiled and signed successfully, the Apps artifact should be uploaded successfully.

If the upload fails because of an upstream GitHub artifact service/client problem, the workflow should surface a useful error message or have a retry/workaround where possible.

Steps to reproduce

Actual behavior

The Apps artifact upload step fails after path/name/root validation and before artifact upload starts, without a useful error message.

The following steps were observed in the same job:

• Build: success
• Sign: success
• Calculate Artifact names: success
• Publish artifacts - apps: failure
• Publish artifacts - build output: success

The successfully uploaded BuildOutput.txt only contains the normal AL compiler output:

Microsoft (R) AL Compiler version 17.0.36.40629
Copyright (C) Microsoft Corporation. All rights reserved

Compilation started for project 'BE-terna Fashion Demo' containing '251' files at '10:00:18.452'.

Compilation ended at '10:00:39.553'.

Evidence / checks performed

• The failing upload path contained one file according to upload-artifact itself.
• The artifact name was accepted as valid.
• The root directory input was accepted as valid.
• The run artifact list did not contain an existing artifact named FashionDemo-main-Apps-28.0.204730.0, so this does not look like an overwrite: false conflict in this run.
• The check-run annotations only contained an unrelated AL-Go warning about missing test apps.
• The next artifact upload in the same job, FashionDemo-main-BuildOutput-28.0.204730.0, succeeded.
• The issue is not reproducibly tied to AL compilation or signing; both had completed successfully before the failure.

Workflow/run details

• Repository using AL-Go: BE-terna-OneBC/BC.BE-Fashion
• Workflow: CI/CD
• Run: https://github.com/BE-terna-OneBC/BC.BE-Fashion/actions/runs/27266243483
• Job: https://github.com/BE-terna-OneBC/BC.BE-Fashion/actions/runs/27266243483/job/80530228908
• Failing job name: Build FashionDemo (Default) / FashionDemo (Default)
• Failing step: Publish artifacts - apps
• Runner: Windows runner via AL-Go setting githubRunner: BC-1
• AL-Go generated action: actions/upload-artifact@bbbca2ddaa5d8feaa63e36b76fdaad77386f024f (v7.0.0)

Additional context (logs, screenshots, etc.)

Related upstream issue

This looks closely related to the open upstream issue in actions/upload-artifact:

• [bug] Upload failed without an error output. actions/upload-artifact#806

That issue describes artifact uploads failing without an error output. The comments also mention that the same behavior occurs with v7, and that rerunning usually succeeds.

Settings/context that may be relevant

The merged AL-Go settings contain:

{
  "generateDependencyArtifact": true,
  "useProjectDependencies": true,
  "shortLivedArtifactsRetentionDays": 1,
  "incrementalBuilds": {
    "onPush": false,
    "onPull_Request": true,
    "onSchedule": false,
    "retentionDays": 30,
    "mode": "modifiedApps"
  }
}

The generated reusable build workflow has artifactsRetentionDays defaulting to 0, and the regular CI/CD workflow call does not appear to pass the shortLivedArtifactsRetentionDays value to _BuildALGoProject.yaml. In this run, the artifact upload therefore used retention-days: 0.

retention-days: 0 is documented by actions/upload-artifact as using the default retention, so this may be unrelated, but it is one visible difference from PR/current-style workflows that explicitly pass the short-lived artifact retention setting.

[aholstrup1]

@SchulzOli
We've been seeing the same issues in our own workflows as well. We are in contact with the GitHub team to get them to address the issue. I believe they found the root cause and are working on rolling out the fix.

[SchulzOli]

@aholstrup1 thanks for the update!