Add support for indirect template + customizations

[freddydk]

Changes included in this PR:

• Support indirect template repository = Point to an existing AL-Go repository as a template, like:

In this case, org/myptetemplate is a standard AL-Go repository, which gets updated as any other AL-Go repository using Update AL-Go System Files. This is a way of standardizing your repository based on type specific AL-Go templates (which can be private or public).

Normally, Update AL-Go System Files follows this mechanism:

Workflows and scripts are read from the template repository and modified based on settings and saved to the repository.

Using an indirect template repository, the picture looks like this:

Workflows and scripts are read from the "real" template repository and modified based on settings. Customizations for workflows in the indirect template repository are applied.

New workflows and scripts from the indirect template repository are copied over and new settings (for repo and for project) are copied over (if they don't already exist in the corresponding settings file).

The final repository can also contain customizations to workflows and the winner here is the indirect template repository (if a custom job or custom step exists in both places).

This PR: freddydk/customized#17 - is an example of a repository with customizations of CI/CD and _BuildALGoProject, which runs Update AL-Go System Files and gets customizations from the indirect template repository (both settings, scripts and workflow customizations)

TODO:

• End 2 End tests
• Unit tests
• Documentation

Documentation on customization capabilities is here: https://github.com/freddydk/AL-Go/blob/customize/Scenarios/CustomizingALGoForGitHub.md

[mortenseifert]

@freddydk, do you have an estimated time of completion for this PR? We've been testing it for a while and are considering deploying it live. However, we're a bit cautious about when the PR will be finalized and whether it will disrupt any modifications we've implemented.

[mazhelez]

Is customALGoSystemFiles supposed to be defined on the indirect template or on the end repositories (the ones that consume the indirect template)?

If it's on the end repos, then it defeats part of the purpose of the indirect template. E.g. in the case of a new common script, the setting needs to be added manually on X repos.

If it's on the indirect template template, then shouldn't relative paths suffice? Does it need to be so complex?

[freddydk]

Not sure what you mean by relative paths?
The Source is an absolute URL to a file to download - rarely something in the same repo.

The setting can be on both.
If it is defined on the indirect template - it is handled when updating the indirect template.
If it is defined on the end repos - it is handled when updating the end repo (not everybody will have an indirect template)

[aholstrup1]

Why not require an indirect template if you want to sync custom scripts? Is there a requirement for two different mechanisms of syncing scripts?

[freddydk]

Those are two different things.
An indirect template is something people create in their organization for types of repos.
custom files could be workflows or scripts created by other people (like the onprem publisher created by a partner)

[aholstrup1]

How do we authenticate to a source if it is in private repo? Is that supported?

[aholstrup1]

Maybe I did something wrong but this didn't work for me. CustomJob-CreateBuildTag is not added in the "needs" block in my repository when I add it in my indirect template.

This is my indirect template:

PostProcess:
    needs: [ Initialization, Build, BuildPP, Deploy, Deliver, CustomJob-CreateBuildTag, DeployALDoc ]
    if: (!cancelled())
    runs-on: [ windows-latest ]
    steps:
      - name: Checkout
        uses: actions/checkout@692973e3d937129bcbf40652eb9f2f61becf3332 # v4.1.7

      - name: Finalize the workflow
        id: PostProcess
        uses: aholstrup1/AL-Go/Actions/WorkflowPostProcess@ab27cdbe117b8c1102c0be563f2e098be079ce37
        env:
          GITHUB_TOKEN: ${{ github.token }}
        with:
          shell: powershell
          telemetryScopeJson: ${{ needs.Initialization.outputs.telemetryScopeJson }}
          currentJobContext: ${{ toJson(job) }}


  CustomJob-CreateBuildTag:
    name: Create Build Tag
    needs: [ Initialization, Build ]
    if: (!cancelled()) && (needs.Build.result == 'success')
    runs-on: [ ubuntu-latest ]
    steps:
      - name: Create Tag
        run: |
          Write-Host "Create Tag"

This is from my repository that uses the indirect template (after running Update AL-Go System Files)

  PostProcess:
    needs: [ Initialization, Build, Deploy, Deliver, DeployALDoc ]
    if: (!cancelled())
    runs-on: [ windows-latest ]
    steps:
      - name: Checkout
        uses: actions/checkout@692973e3d937129bcbf40652eb9f2f61becf3332 # v4.1.7

      - name: Finalize the workflow
        id: PostProcess
        uses: aholstrup1/AL-Go/Actions/WorkflowPostProcess@ab27cdbe117b8c1102c0be563f2e098be079ce37
        env:
          GITHUB_TOKEN: ${{ github.token }}
        with:
          shell: powershell
          telemetryScopeJson: ${{ needs.Initialization.outputs.telemetryScopeJson }}
          currentJobContext: ${{ toJson(job) }}


  CustomJob-CreateBuildTag:
    name: Create Build Tag
    needs: [ Initialization, Build ]
    if: (!cancelled()) && (needs.Build.result == 'success')
    runs-on: [ ubuntu-latest ]
    steps:
      - name: Create Tag
        run: |
          Write-Host "Create Tag"

[freddydk]

Strange - when you add that to the indirect template - it shouldn't do anything in the end repo.
Will have a look

[aholstrup1]

Shouldn't it add CustomJob-CreateBuildTag to the needs block in PostProcess? 🤔 Maybe I misunderstood it