AL-Go/Workshop/Dependencies2.md

Dependencies #2 - Dependencies to AL-Go projects in other repositories

Many partners have a set of common helper functions, tables and other things, which they reuse in other apps.

With AL-Go for GitHub, the recommendation is to create a Common repository, which has one or more projects, which can be used in several of your other apps.

So, let's setup a single-project common repository like this. Navigate to https://aka.ms/algopte to create a new repository. Click Use this template and select Create a new repository. Select your organization as owner, specify a name and select Public.

Create 2 apps within the repository using the Create a new app workflow called Common and Licensing, using the following parameters:

Name	Value
Use workflow from	Branch: main
Project name	.
Name	Common
Publisher	<your publisher name>
ID Range (from..to)	60000..60099
Include Sample Code	🔲
Direct Commit	☑️
Use GhTokenWorkflow	🔲

and

Name	Value
Use workflow from	Branch: main
Project name	.
Name	Licensing
Publisher	<your publisher name>
ID Range (from..to)	60100..60199
Include Sample Code	🔲
Direct Commit	☑️
Use GhTokenWorkflow	🔲

Leaving out the sample code in order to avoid name clashes.

Wait for both workflows to complete.

Under Code locate the app.json file for the Common app and copy id, name, publisher and version to the clipboard.

Now locate the app.json file for the Licensing app and create a dependency to the Common app and commit the changes.

Also copy the id, name, publisher and version from the Licensing app to the clipboard as well.

Select Actions and wait for the CI/CD workflow to complete.

Now, navigate back to your multi-project repository, which you created here.

Add a dependency to the Licensing app from the Common repository, from the mysolution.w1 app in the W1 project.

And as expected, the builds will fail.

In this example using the useProjectDependencies mechanism, but builds would also fail when using include.

In this workshop, I will describe two ways to to make this work.

Using appDependencyProbingPaths

In the MySolution repository, navigate to Settings -> Secrets and Variables -> Actions and select Variables. Create a new repository variable called ALGOREPOSETTINGS with this content:

  "appDependencyProbingPaths": [
    {
      "repo": "freddydkorg/Common",
      "release_status": "latestBuild"
    }
  ]

replacing freddydkorg with your organization name obviously.

!NOTE

Make sure you create a repository variable and not a repository secret

This setting means that all projects in this repository will download the latest build from freddydkorg/Common and a subsequent build will succeed. Go to Actions, select the CI/CD workflow, click Run workflow and wait for the workflow to complete.

!NOTE

You can also define appDependencyProbingPaths in the settings file for individual projects (f.ex. W1 project). This would also work when using useProjectDependencies. When using include however the DK and US projects would fail as they would include the source code for the W1 project, but not the settings (i.e. the appDependencyProbingPaths).

Using GitHub Packages

!NOTE

If you already added appDependencyProbingPaths, then please remove these settings before continuing, making your build fail again.

In order to use GitHub Packages for dependency resolution, we need to create an organizational secret called GitHubPackagesContext. The format of this secret needs to be compressed JSON containing two values: serverUrl and token. Example:

{"token":"ghp_XXX","serverUrl":"https://nuget.pkg.github.com/freddydkorg/index.json"}

Where ghp_XXX should be replaced by a personal access token with permissions to write:packages and freddydkorg should be replaced by your organization name.

!NOTE

Fine-grained personal access tokens doesn't support packages at this time, you need to use classic personal access tokens.

To create a personal access token, navigate to https://github.com/settings/tokens/new, give it a name and select write:packages.

!NOTE

You can also use the BcContainerHelper function New-ALGoNuGetContext to create a correctly formed JSON structure.

Go to your organization settings and create an organizational secret called GitHubPackagesContext with the your secret value.

Now, navigate to your Common repository and run the CI/CD Workflow. Inspect the workflow summary after completion:

Notice the Deliver to GitHubPackages job. By creating the GitHubPackagesContext secret, you have enabled Continuous Delivery to GitHub Packages.

Now, click Code and see that you have 2 Packages delivered from the repository:

Click Packages, which will take you to Packages in your organizational profile. All packages are stored on the organization with a link to the owning repository:

Next, navigate to your MySolution repository (where you deleted the ALGOREPOSETTINGS repository variable) and run the CI/CD workflow and magically, all dependencies are now also resolved.

Looking into the logs under the Build step, you will find that Resolving Dependencies will find that it is missing the Licensing dependency and then, under installing app dependencies, it searches GitHub Packages to locate the missing dependencies (+ their dependencies)

and looking at packages for the organization, we will now see that there are 5 packages - 3 of them published from the MySolutions repository:

Continuous Delivery is not only GitHub Packages. Let's have a look at continuous delivery...

---

Index  next