Set default values on workflow_dispatch input

[jwikman]

Most of the workflows in AL-Go can be started manually on GitHub.com.
Several of them has input values that can be set by the user, up to 10 at most (which is the max number of workflow_dispatch input on GitHub).

We will have a challenge to get all our devs to always pick the right options here.

Several of these input values could have better default values, depending on how you have set up AL-Go.
Examples of input values that we always need to change:

• directCommit
• useGhTokenWorkflow
• updateVersionNumber

I suggest a new setting that lets us configure default values for these input values. When configured, these default settings should be set in the yaml files when the Update AL-Go System Files workflow is updating a repository.
Additionally, it would be nice to also be able to hide input values, ie. when configured, the input value is not shown at all - it will use the default value directly.

Something like this:

  "workflowInputDefaults": [
    {
      "workflow": "Create release",
      "defaults": [
        {
          "name": "directCommit",
          "value": true
        },
        {
          "name": "useGhTokenWorkflow",
          "value": true,
          "hide": true
        },
        {
          "name": "updateVersionNumber",
          "value": "+0.1"
        }
      ]
    },
    {
      "workflow": "Update AL-Go System Files",
      "defaults": [
        {
          "name": "directCommit",
          "value": true
        }
      ]
    }
  ]

[frottke]

I really like the idea of having configurable default values for workflow inputs and the option to hide them would be a great improvement.
It would make it much easier for teams to ensure consistent settings and reduce the risk of mistakes when running workflows manually.

[jwikman]

After intense use of AL-Go a couple of months, this is the single most annoying thing in AL-Go.
During our release process, several workflows are manually triggered, with a LOT of clicking here and there to get the settings in the way we want.
The current way is very error prone!

I believe that the hide functionality proposed here could be implemented later, as a feature on its own.

@mazhelez are you (and the team) OK with me creating a PR for this? Would the proposed schema work with your thinking of how the settings object should look like?

[jwikman]

@frottke any thoughts on the proposed settings schema?
(Ignore the hide property for now)

[frottke]

Looks good overall, the idea makes sense.

One thing to consider: maybe we should reference the workflow file path (e.g. .github/workflows/create-release.yml) instead of the workflow name ("Create release"). The display name can change, so the path would probably be more stable. We could also just check how AL-Go currently identifies workflows for other purposes and use the same logic there which would keep things consistent.

About the hide option (I'm not ignoring it, because it seems to be really nice to have) that one might be a bit tricky.
GitHub doesn’t really support hiding workflow_dispatch inputs as you might know already. To actually hide one, we’d need to remove the input definition from the workflow file and inject the value somewhere else (like in env or with) if it is an mandatory field but the same input value every time.
That would mean modifying the workflow file itself, so the “Update AL-Go System Files” workflow would need to run afterwards. It’s doable, but probably more of a nice to have than something we need right away.

[jwikman]

One thing to consider: maybe we should reference the workflow file path (e.g. .github/workflows/create-release.yml) instead of the workflow name ("Create release"). The display name can change, so the path would probably be more stable. We could also just check how AL-Go currently identifies workflows for other purposes and use the same logic there which would keep things consistent.

I was about to use the same matching as for ConditionalSettings. It is a bit quirky, but then at least we're consistent.
We could, on the other hand, also add an alternate naming option, as your yaml file path, but then it should be implemented for both this and ConditionalSettings. I think we'll leave that to a separate PR if needed later.

About the hide option (I'm not ignoring it, because it seems to be really nice to have) that one might be a bit tricky. GitHub doesn’t really support hiding workflow_dispatch inputs as you might know already. To actually hide one, we’d need to remove the input definition from the workflow file and inject the value somewhere else (like in env or with) if it is an mandatory field but the same input value every time. That would mean modifying the workflow file itself, so the “Update AL-Go System Files” workflow would need to run afterwards. It’s doable, but probably more of a nice to have than something we need right away.

You are absolutely correct here. That would be the way to solve this. Not a very simple task, but doable (I believe at least 🫣).

But: This is also the case for the default value feature, we need to apply them to the yaml file in the “Update AL-Go System Files” workflow. But that would be much easier than replacing input references with our value, as needed with the "hide" feature.

The big value in this idea, IMHO, is the "default value" feature. I also think this is quite easy to solve.

The "hide" feature is a nice-to-have that we could discuss further later. This is also more advanced to implement fool proof for all workflows (including custom workflows)

[frottke]

But: This is also the case for the default value feature, we need to apply them to the yaml file in the “Update AL-Go System Files” workflow. But that would be much easier than replacing input references with our value, as needed with the "hide" feature.

The big value in this idea, IMHO, is the "default value" feature. I also think this is quite easy to solve.

The "hide" feature is a nice-to-have that we could discuss further later. This is also more advanced to implement fool proof for all workflows (including custom workflows)

I completely forgot that the default value also needs to be written to the file.
Given that we have to modify the file anyway, we might just as well implement the "hide" feature as well, after all, it’s just a boolean. -> Replacing manual input with default and then hiding it.

[jwikman]

@frottke I think I got this working now.

I've created a PR with the default values.
This is without the "hide" functionality, since that became a bit of a challenge to do as robust as I wanted.

But I think I also got that to work as well but will create another PR for that later.

If you want to give it a try, you can use my work branch for this feature. Then update AL-Go system files against this: https://github.com/jwikman/AL-Go@w/johwik/1952-Hide-default-values-from-workflow_dispatch-input

The Release notes includes some information on what this is.
Also the settings docs is updated