[Question]: run-alvalidate + app upgrade testing for AL-Go?

[SteveKrisjanovsD365]

Question

We're currently using a local server and bccontainer's "run-alvalidate" to catch any codecop errors in the newer app when comparing against the previous app(s) via the -previousApps parameter.

we also use al-go (for both PTE and AppSource templates) but there doesn't appear to be any documentation on how testing app upgrades is handled. There doesn't appear to be a "previousApps" setting to utilize. Our DeliverTo pipelines were failing because one of our developers increased the length of a primary key field. AL-Go's CICD build step didn't catch the problem but deploying to an environment raised an error.

to ensure that no errors were missed, we invoked run-alvalidate locally on the apps in question

Does AL-Go handle validating an app from version X to version Y and if so, can you explain how this works?

[freddydk]

If you create a release of your app - it will be used as the previous version for AL Cops and upgrade tests.
See more here: https://github.com/microsoft/AL-Go/blob/main/Workshop/Releasing.md

[SteveKrisjanovsD365]

thanks @freddydk I figured it had to do with releases. We havent explored release workflows yet.

some backstory - we developed and published our inititial builds of our apps to apprource not using AL Go at all.

We've since transitioned those repos to AL-Go and we're in the process of introducing new and modified AL objects. Because of this there have been no "Releases" created yet as the codebase in the [main] branch is an ongoing work-in-progress.

given the situation I guess we'll have to continue using local run-alvalidate until we have a stable release to create in algo

good to know this is automatically handled provided there are releases built by algo! thanks again for the clarification 👍

[freddydk]

You could create a release manually by clicking Releases -> Draft New Release and specify 0.0.1 like:

Then upload a .zip file with the apps you are using for your run-alvalidation to this UI.
After creating this release - it will use these binaries for upgrade tests (even though the source for this release doesn't match the binaries)

This is standard GitHub functionality and should work (I haven't tried).
Maybe the .zip file needs to be named as the .zip file in a release - like: <Project>-<branch>-Apps-<version>.zip where <Project> is the name of the project in a multi-project repo (or the name of the repo in a single project repo).

[SteveKrisjanovsD365]

Thanks I'll give it a shot.

The versioning in the original apps was built outside algo so the app versioning weren't compatible with algo's versioning strategies.

I didn't want to pester you about how to create a release manually so thanks again for sharing your input!

[SteveKrisjanovsD365]

@freddydk I'm trying out your "manual release" suggestion now.

regarding the source code being different than the binary, thats not a concern. I added a corresponding version tag to the commit (Nov 15 2024) the source code for out appsource apps (AL Go wasn't used at the time) were added to AL-Go. after that commit I cleaned up the versioning for al-go versioning compatibility

this way the release process generates a source code zip that matches whats in the --Apps-.zip file(s)

running CICD againt [main] now. crossing fingers! with any luck the logs will show its validating the current [main] branch against this initial mock release

[SteveKrisjanovsD365]

@freddydk I just tried your suggestion i.e. create a release manually outside AL-go and insured the release app zip artifacts are named <Project>-<branch>-Apps-<version>.zip

I created the release from [main] but before I created it, I added a version tag to the older commit where the apps were initially introduced to the algo repo back in mid-November. that way the source code extracted for this manual release belongs to the code that resided in [main] at that specific git tag / commit.

Despite this, algo CICD is successfully locating the release but further down the CA and W1 build pipeline logs it shows previous apps >> none. I wasn't expecting that.

Release details/contents are as follows:

release tag: v2402.7800.60
projects: .W1, .CA (two apps in .W1, two more in .CA)
NOTE - the latest [main] branch codebase has a new project .AU, but the AU apps were not yet deveveloped yet at the time when release v2402.7800.60 for .W1 and .CA were uploaded to appsource

release app zip contents:

• W1-main-Apps-2402.7800.60.3.zip
  • 365Vertical_365 Cannabis Cultivation_2402.7800.60.3.app
  • 365Vertical_365 Cannabis Processing and Distribution_2402.7801.60.3.app
• CA-main-Apps-2402.7800.60.3.zip
  • 365Vertical_365 Cannabis CA Compliance_2402.7801.60.3.app
  • 365Vertical_365 Cannabis CA Cultivation_2402.7800.60.3.app

i created a mock branch with destructive changes across all four .W1 and .CA apps and momentarily merged it into [main] to repro destructive schema changes across all four apps (e.g. field name change, increasing a PK field size, etc). Despite this, CICD build succeeded and didn't pick up any previous apps to validate against

attached is the CICD logs for review where I was expecting the build pipelines for .CA and .W1 to fail but they succeeded

logs_33677322079.zip