[Bug]: deliverToAppSource.ProductId needs to be specified (Library app)

[fvet]

AL-Go version

8.1

Describe the issue

In a multi-project repo with multiple AppSource apps and one library app, using the 'Publish to AppSource' action for all projects does not exclude the library app, but fails with

deliverToAppSource.ProductId needs to be specified in Foundation/.AL-Go/settings.json in order to deliver to AppSource

Expected behavior

If 'Publish to AppSource' action is ran with '*' to include all projects - in a multi-project setup - only the AppSource configured apps should be included. Any library apps should be excluded.

Workaround:
The user might manually indicate the projects to be uploaded (instead of *), which is cumbersome if you'd have a multi-project with dozens of AppSource apps and few library apps.

Steps to reproduce

One repo, 3 projects (apps)

• Foundation: library app
• Companyweb : AppSource app with dependency on Foundation
• Liza : AppSource app with dependency on Foundation

Config for Foundation

{
  "$schema": "https://raw.githubusercontent.com/microsoft/AL-Go-Actions/v8.1/.Modules/settings.schema.json",
  "country": "us",
  "appSourceCopMandatoryAffixes": [
    "CWEBF"
  ],
  "projectName": "Foundation",
  "rulesetFile": "App/.vscode/app.ruleset.json"
}

Config for Companyweb

{
  "$schema": "https://raw.githubusercontent.com/microsoft/AL-Go-Actions/v8.1/.Modules/settings.schema.json",
  "country": "be",
  "appSourceCopMandatoryAffixes": [
    "CWEB"
  ],
  "projectName": "Companyweb",
  "rulesetFile": "App/.vscode/app.ruleset.json",
  "deliverToAppSource": {
    "productId": "***",
    "mainAppFolder": "App",
    "continuousDelivery": false,
    "includeDependencies": [
      "Dynavision*Foundation*.app"
    ]
  },
  "generateDependencyArtifact": true
}

Config for Liza

{
  "$schema": "https://raw.githubusercontent.com/microsoft/AL-Go-Actions/v8.1/.Modules/settings.schema.json",
  "country": "nl",
  "appSourceCopMandatoryAffixes": [
    "CWEBL"
  ],
  "projectName": "Liza",
  "rulesetFile": "App/.vscode/app.ruleset.json",
  "deliverToAppSource": {
    "productId": "***",
    "mainAppFolder": "App",
    "continuousDelivery": false,
    "includeDependencies": [
      "Dynavision*Foundation*.app"
    ]
  },
  "generateDependencyArtifact": true
}

Run 'Publish to AppSource' action

Failure on

[Deliver to AppSource](https://github.com/DynavisionISV/Companyweb/actions/runs/21254191419/job/61163944199#step:5:244)
Unexpected error when running action. Error Message: deliverToAppSource.ProductId needs to be specified in Foundation/.AL-Go/settings.json in order to deliver to AppSource, StackTrace: at <ScriptBlock>, /home/runner/work/_actions/microsoft/AL-Go-Actions/v8.1/Deliver/Deliver.ps1: line 372 <- at <ScriptBlock>, /home/runner/work/_temp/3dfbf039-a1b6-4795-a0f6-467befb4470d.ps1: line 3 <- at <ScriptBlock>, /home/runner/work/_actions/microsoft/AL-Go-Actions/v8.1/Invoke-AlGoAction.ps1: line 21 <- at <ScriptBlock>, /home/runner/work/_temp/3dfbf039-a1b6-4795-a0f6-467befb4470d.ps1: line 2 <- at <ScriptBlock>, <No file>: line 1

Possible cause:

Foundation is included (as part of *)

Expected behavior

When using *, all projects can be evaluated, but only those with deliverToAppSource settings should be included, others (library apps) should be skipped

Additional context (logs, screenshots, etc.)

logs_55110685095.zip

[mazhelez]

Hi @fvet

If I understand correctly, in your setup there are AppSource apps that depends on an app that isn't published to AppSource. Isn't that an anti-pattern? How are customers going to install Liza or Companyweb if Foundation isn't on AppSource?

Also, I believe you use the AppSource template, so the assumption is that all of the apps, in all of the AL-Go projects in the repo, are AppSource apps. The check is there to prevent misconfiguration. E.g. you forget to setup deliverToAppSource for some of the apps.

[freddydk]

Hi @fvet

If I understand correctly, in your setup there are AppSource apps that depends on an app that isn't published to AppSource. Isn't that an anti-pattern? How are customers going to install Liza or Companyweb if Foundation isn't on AppSource?

Also, I believe you use the AppSource template, so the assumption is that all of the apps, in all of the AL-Go projects in the repo, are AppSource apps. The check is there to prevent misconfiguration. E.g. you forget to setup deliverToAppSource for some of the apps.

I think the library app is indeed on appsource, it is just a library app on appsource (meaning that it needs to be included when publishing the 2 other apps as a library app) and will not be installable without the other.

I assume the scenario woks if you specify Liza,Companyweb - right?

[freddydk]

Checking for the ProductId could easily be done before

AL-Go/Actions/Deliver/Deliver.ps1

Line 355 in 19a9008

if ($type -eq 'Release' -or $projectSettings.deliverToAppSource.continuousDelivery) {

and then issue an information instead of an error and then remove the check in

AL-Go/Actions/Deliver/Deliver.ps1

Line 375 in 19a9008

if (!$projectSettings.deliverToAppSource.ProductId) {

[fvet]

I think the library app is indeed on appsource, it is just a library app on appsource (meaning that it needs to be included when publishing the 2 other apps as a library app) and will not be installable without the other.

I assume the scenario woks if you specify Liza,Companyweb - right?

100% right, the Foundation app is on AppSource, but as library app only.
Using Liza,Companyweb does work indeed.

[freddydk]

The exact same scenario you are describing is used in https://github.com/microsoft/bcsamples-bingmaps.appsource - and the latest publish actually works:

https://github.com/microsoft/bcsamples-bingmaps.appsource/actions/runs/21210165002/job/61017930353

Looking at the code, I don't understand why right now?

[freddydk]

Found the reason - and the bingmaps repo will also fail if you run Publish to appsource.
The BingMaps repo is setup for continuous delivery and ContinuousDelivery is set to true on Main Project and not on Library project.
This causes this line:

    if ($type -eq 'Release' -or $projectSettings.deliverToAppSource.continuousDelivery) {

to skip the delivery of library apps during CI/CD, but not during publish (i.e. release).

this is a clearly a bug.
I will create a fix for this.

[aholstrup1]

@freddydk I wonder if this is just as much a feature as a bug? In this case it fails on a library project but generally we can't really know if the maintainer meant to release that project or they didn't. It could've been a third AppSource app that the maintainer wanted to release but forgot to set up deliverToAppSource settings for. In that case, you'd probably want a failure rather than the workflow silently continuing 🤷‍♂️

[FreundDK]

@freddydk I wonder if this is just as much a feature as a bug? In this case it fails on a library project but generally we can't really know if the maintainer meant to release that project or they didn't. It could've been a third AppSource app that the maintainer wanted to release but forgot to set up deliverToAppSource settings for. In that case, you'd probably want a failure rather than the workflow silently continuing 🤷‍♂️

The intention was that it works like after this bugfix - which is also what my test-repo (Bingmaps.appsource) tests - I just didn't test that repo with publish to appsource (only during CI/CD), IMO it is clearly a bug.

Difference is that if the user wants to publish the apps in the project and it doesn't work - he will investigate and add productId (logs will tell). The Library app project is very common in BC world.