[Bug]: DeliverToAppSource ignores includeDependencies and packages additional dependency apps

[rm-eyna]

AL-Go version

9.0

Describe the issue

We are using AL-Go for GitHub AppSource template v9.0.

Our app has the following dependency structure:
Advanced Package Mgt
├─ Customer License Management
└─ Detailed Inventory

The repository settings contain:

We expect only the Customer License Management dependency to be packaged into the generated .libraries.zip.

However, the generated libraries package still includes additional dependency apps which do not match the configured filter.

Repository Settings
"appDependencyProbingPaths": [
{
"repo": "EYNA-SOFTEAM/MKT-EYN-CUSTOMER-LICENSE-MANAGEMENT",
"version": "latest",
"release_status": "release"
},
{
"repo": "EYNA-SOFTEAM/MKT-EYN-DETAILED-INVENTORY",
"version": "latest",
"release_status": "release"
}
],
"deliverToAppSource": {
"productId": "ee0e0e94-831b-4d2a-926f-61c35368e72a",
"mainAppFolder": "EYN-Advanced-Package-Mgt",
"includeDependencies": [
"Eyna Softeam, S.L._Eyna Customer License*.app"
]
}

Observed Behavior
The Deliver workflow generates: Eyna Advanced Package Mgt._2.4.47.0.libraries.zip

Contents::
Eyna Customer License Management_1.0.2.0.app
Eyna Customer License Management_2.0.8.0.app
Eyna Detailed Inventory_2.0.15.0.app

Expected behavior

Generated .libraries.zip should contain only files matching:
Eyna Softeam, S.L._Eyna Customer License*.app

For example:
Eyna Customer License Management_2.0.8.0.app

or whichever matching files AL-Go considers valid.
Dependency apps that do not match the configured includeDependencies filter should not be packaged.

Question
Is includeDependencies expected to filter the content of the generated .libraries.zip?
If yes, this appears to be a bug.
If no, could you clarify the intended behavior and the supported way to exclude specific dependency apps from the AppSource libraries package?

The Deliver workflow log correctly reads and displays the includeDependencies setting, however the generated .libraries.zip still contains dependencies that do not match the configured pattern. This suggests that the filtering logic is either not applied when creating the library package or behaves differently than documented.

Steps to reproduce

1. Create an AL-Go AppSource repository using AL-Go v9.0.

2. Configure multiple dependency repositories using appDependencyProbingPaths:
   "appDependencyProbingPaths": [
   {
   "repo": "repoA",
   "version": "latest",
   "release_status": "release"
   },
   {
   "repo": "repoB",
   "version": "latest",
   "release_status": "release"
   }
   ]

3. Configure deliverToAppSource with a dependency filter:
   "deliverToAppSource": {
   "productId": "",
   "mainAppFolder": "",
   "includeDependencies": [
   "_*.app"
   ]
   }

4. Enable CI/CD delivery to AppSource.
   generateDependencyArtifact": true

5.Run the CI/CD workflow until the Deliver to AppSource stage is executed.

6.Inspect the generated artifacts:
Dependencies.zip
.libraries.zip

Additional context (logs, screenshots, etc.)

No response

[aholstrup1]

Roger Molina Santiago (@rm-eyna) Any chance you can include your logs for the CI/CD workflow? It would be helpful in order to understand where the issue is.

Does the repo only contain the "Advanced Package Mgt" app and that's the only app that you compile during your build?

[rm-eyna]

Hi Alexander Holstrup (@aholstrup1).

Here goes the v9.0 try

I tried in v9.1 and the second App don't go in the library zip file. But in the first extension are still going two versions of the same App.

Is There the possibility of do something like "Latest" in the :
"includeDependencies": [
"_*.app" - Latest
]
?

logs_83953199658.zip

[aholstrup1]

Ah I think I might've misunderstood you. When I look in the log, it does seem like it delivers exactly the apps you expect it to i.e. the Detailed Inventory app is not included in the submission. Initially I had the understanding that it somehow got included in the Appsource submission anyway, but reading your issue again, your question was around the generated dependency artifact? Just want to make sure I understand correctly.

2026-08-04T22:46:19.4498649Z Main App File:
2026-08-04T22:46:19.4518483Z - Eyna Softeam, S.L._Eyna Advanced Package Mgt._2.4.47.0.app
2026-08-04T22:46:19.4526046Z Library App Files:
2026-08-04T22:46:19.4553959Z - Eyna Softeam, S.L._Eyna Customer License Management_1.0.2.0.app
2026-08-04T22:46:19.4562236Z - Eyna Softeam, S.L._Eyna Customer License Management_2.0.8.0.app
2026-08-04T22:46:19.4569876Z Submitting to AppSource

Is includeDependencies expected to filter the content of the generated .libraries.zip?
If yes, this appears to be a bug.
If no, could you clarify the intended behavior and the supported way to exclude specific dependency apps from the AppSource libraries package?

Not exactly, no. That filtering happens at the time of submission to AppSource. Not at the time of publishing the artifact to your build artifacts. As far as I can tell from the Deliver log (2_Deliver to AppSource.txt) the filtering does happen, but the intermediate dependency artifact does contain all of the dependency apps. I believe that is by-design.

[aholstrup1]

Roger Molina Santiago (@rm-eyna) Did that answer your question? :)

[rm-eyna]

Hi Alexander Holstrup (@aholstrup1)

Thanks for the clarification.

I think the main issue is not Detailed Inventory anymore.
In version 9.0, Detailed Inventory was also included in the libraries package, while in 9.1 it is no longer included. That behavior looks correct to me.

The remaining problem is that multiple versions of the same dependency are still being included.
For example, both versions of Customer License Management are added to the libraries package:
•Customer License Management 1.0.x
•Customer License Management 2.0.x

When AppSource validates the submission, it fails because multiple versions of the same dependency are present.

The current workaround is to keep updating the includeDependencies filter every time a new version is released, otherwise older versions accumulate over time. This becomes difficult to maintain, especially when managing several dependency apps.

Is there currently a supported way to automatically select only the latest version of a dependency?
For example, a latest option, or logic that automatically keeps only the highest version for a given AppId, would make this scenario much easier to manage.

From my perspective, the current behavior feels like a product limitation because it requires ongoing manual maintenance of dependency version filters.

[aholstrup1]

Roger Molina Santiago (@rm-eyna) Mmh right... I see. A couple of questions just to understand your setup better:

Do you have generateDependencyArtifact enabled on all three repos? If you are not shipping to AppSource out of the "Customer License Management" and "Detailed Inventory" I wonder if you need it there. With that turned off, I think you would only get the "Customer License Management 2.0.x" pulled into your "Advanced Package Mgt" repo.

If you do need generateDependencyArtifact in all repos, how is the "Detailed Inventory" repo set up? I'm wondering why it is pulling the v1 version of the "Customer License Management" rather than v2? Are you using appDependencyProbingPaths there too? And is it set up to pull latest?

[rm-eyna]

Hi Alexander Holstrup (@aholstrup1)

All three repositories are configured the same way.

They all have generateDependencyArtifact = true enabled.

Customer License Management is a shared library that is used by the other two extensions.

Detailed Inventory is an AppSource app, and Advanced Package Management is also an AppSource app that additionally depends on Detailed Inventory.

Both repositories have appDependencyProbingPaths configured, and yes, the Customer License Management dependency is configured to pull the latest version.

What I find surprising is that despite using the latest setting, both Customer License Management v1 and v2 end up being included in the dependency artifacts and ultimately create issues during AppSource validation.

Thanks