Use groups, sections, and secret masking in task output for better navigation and readability

[rhyskoedijk]

Use groups, sections, and secret masking in task output for better navigation and readability.

Mask well-known environment info as secrets

Most user's environments are private and they're less likely to share diagnostic info when it exposes information about their environment or organisation.

The hostname, virtual directory, organisation, project, repository, author name/email, and access token values are all masked in task output. Repository directory and file names or the contents of files are not masked as they are critical for diagnosing problems where as the other information is already well-known to the user. Although it doesn't make the task log completely anonymous, it does remove a significant amount of the identifiable information.

Group each dependabot update job

Each Dependabot job is now wrapped in a collapsible group; This allows easier navigation when there are multiple jobs in a pipeline run (e.g. update all, update PR1, update PR2, etc).

Section each executable operation and each processed output

Each logical block of functionality is now sectioned within the parent group; This provides better readability and easier navigation of the logs.

[mburumaxwell]

Thanks for this contribution. Sectioning and masking are brilliant. Masking happens automatically on GitHub Actions but not Azure DevOps.

As regards masking,

• The hostname, organization, and virtual path may still be useful when detecting whether it's the Azure DevOps server or the hosted version.
• Do we need to mask the project id and the user?
• Should we make this optional?

[rhyskoedijk]

The hostname, organization, and virtual path may still be useful when detecting whether it's the Azure DevOps server or the hosted version.

I did think about this, but also assumed that any on-premise environment probably doesn't want their hostname exposed (assuming it is public). If the only concern is detecting cloud/on-prem, maybe we can print a "Environment Type: Cloud/On-Premise" to debug log when parsing config?

Do we need to mask the project id and the user?

Probably not, just added it for completeness; I can remove it.

Should we make this optional?

Do you have any preference? I could add a task input to control it, or maybe toggle it based on the System.Debug variable? Maybe only do the masking if debug is true? Debug runs are probably the most likely scenario a user would want to copy/paste the logs and share them externally?

[mburumaxwell]

I did think about this, but also assumed that any on-premise environment probably doesn't want their hostname exposed (assuming it is public). If the only concern is detecting cloud/on-prem, maybe we can print a "Environment Type: Cloud/On-Premise" to debug log when parsing config?

Your suggestion on this is better.

Do you have any preference? I could add a task input to control it, or maybe toggle it based on the System.Debug variable? Maybe only do the masking if debug is true? Debug runs are probably the most likely scenario a user would want to copy/paste the logs and share them externally?

Linking it to System.Debug seems ideal. However, anything sensitive should remain masked/omitted by default, similar to how secrets work in GitHub actions. Giving it more thought, we should assume the user already has the necessary values elsewhere, and should they not, they can regenerate them (i.e. tokens or keys).

[rhyskoedijk]

Your suggestion on this is better.

A debug log during config parse now identifies if the environment is on-premise or not.

Linking it to System.Debug seems ideal. However, anything sensitive should remain masked/omitted by default, similar to how secrets work in GitHub actions. Giving it more thought, we should assume the user already has the necessary values elsewhere, and should they not, they can regenerate them (i.e. tokens or keys).

If I understand this correctly, no change? I somewhat agree that the environment owner never needs to know these values (even in a debug run); They can easily infer them from what they know about the environment or in the case of access token secrets, regenerate them.

Let me know if you want any more changes made around this, otherwise it is ready to go