Override array settings

[jwikman]

AL-Go supports a very flexible settings hierarchy, where most specific setting is applied. This is very neat when you want to make sure that settings are streamlined within your organization.

But this only works for simple types! If the setting is an array or an object, the settings for each level are instead merged.

The logic for this is found in Actions\.Modules\ReadSettings.psm1 in the MergeCustomObjectIntoOrderedDictionary() function, and it is quite obvious that this is by design:

    # If the property exists in the source object:
    # If the property is an Object, call this function recursively to merge values
    # If the property is an Object[], merge the arrays
    # If the property is a simple type, replace the value in the destination object with the value from the source object

We try to put as much settings as possible in OrgSettings, and only use repo or project settings when really needed.
But when we want to set a different setting on repo level for one single repo, and the setting is an array (or object for that matter, but have not had that issue yet), we cannot override the OrgSettings. This forces us to move that setting to RepoSettings for all repos, which kind of sucks. 😕

Hence, I suggest implementing a mechanism where we also can override array and object settings.

If you agree on this, we can start discussing how this could be implemented with backward compatibility.

[mazhelez]

Hi @jwikman

I understand your scenario, and it was indeed not taken into consideration when the settings logic was implemented. But we are always open to discussing ways to unblock such scenarios.

Out of curiosity, do you have a solution in mind? A solution that is, as you said, backwards compatible.

[jwikman]

Hi @mazhelez,

One way could maybe be to add a new setting, something like RemoveProperties. An array with texts, that can be added on all levels.

When looping through the settings of a setting file, when about to apply the settings to the Settings object, always look for this property when in a new object. If found, all matching properties should be removed from the Settings object before applying the settings in the current level.

Example:
We've got this (among a lot of other settings) in OrgSettings:

{
    "CICDPushBranches": [
        "main",
        "releases/*"
    ],
    "DeliverToGitHubPackages": {
        "ContinuousDelivery": true,
        "Branches": [
            "main",
            "releases/*"
        ]
    }
}

Now, let's say I have one single repo in this org, where we for some reasons have other naming on the releases branch, "OnPrem/*".
Then we could have something like this in repo settings:

{
    "RemoveProperties": [
        "CICDPushBranches"
    ],
    "CICDPushBranches": [
        "main",
        "OnPrem/*"
    ],
    "DeliverToGitHubPackages": {
        "RemoveProperties": [
            "Branches"
        ],
        "ContinuousDelivery": true,
        "Branches": [
            "main",
            "OnPrem/*"
        ]
    }
}

If a repo should not deliver to GitHub Packages I would add these repo settings:

{
    "RemoveProperties": [
        "DeliverToGitHubPackages"
    ]
}

I first thought about this with an "OverrideProperties" setting, but removing setting from a higher level would also open up for totally removing a setting, not only override with new values.

Let me know what you think, this was just on top of my head right now.

[mazhelez]

That's quite an interesting approach!
What would be a scenario for removing a setting? In your scenario, the setting is defined on both levels, so it's technically on override.

[jwikman]

@mazhelez, my second example is such a scenario, isn't it? 🙂

[mazhelez]

Ah, yes, it does. My bad for not paying attention.

I think I like your idea.