Support Azure Devops self-hosted agents

[onybo]

Description

I would really like to see support for Self-hosted agents in addition to the current Microsoft hosted agents.

I am aware that a similar issue was raised some time ago, but in the previous issue it was more about on-prem agents while I think it is really about supporting the more general concept of self-hosted agents, which may be on-prem or anywhere else.

It seems that the current implementation of AzurePipelines in nuke is only for Microsoft hosted agents.
As far as I know, the generated yaml only works when using Microsoft hosted agents and the AzurePipelines attribute can't be configured so that the yaml file required for a Self-hosted agent is generated.

Furthermore the generated yaml is assuming that all jobs/targets should go into all stages, and each stage is linked to a specific vmImage.
E.g. adding an AzurePipelines attribute like this will produce two almost identical stages including all targes as jobs (only difference would be the vm image):

[AzurePipelines( 
    AzurePipelinesImage.UbuntuLatest,
    AzurePipelinesImage.Ubuntu1804,
    InvokedTargets = new[] { nameof(Compile) })]

Producing a yaml wich would look like this:

Running all targets (jobs) on all images may make sense when all agents have the same set of installed tools like the Microsoft hosted agents, but when using self hosted agents this may not make as much sense.

When using self hosted agents we should not be specifying the vmImage property of the pool, but rather the name of the pool that we want to use.
When self hosted agents they may also have different capabilities and we need to control what pool is used for a specific target/job.
E.g. the test targets/jobs may require different tools than what is needed for the build job.

I suggest to introduce a new AzureStageAttribute which could accept either a stage name or the image.
As we can have any combination of Stages running on either Microsoft hosted and some on self-hosted I think we should allow for multiple AzureStageAttributes on the Build object.
The reason for this is that attempting to support both in a single AzurePipelinesAttribute as was done in the previous attempt to solve issue 1019, may become a bit "not a great implementation".
This would require a change in BuildServerConfigurationGenerationAttributeBase as well.

The attribute would be used when generating the pool property in the yaml.
We would set either vmImage or name depending on what was passed to the AzureStageAttribute.
vmImage would be used for Microhost hosted agents as today, name would be used for self-hosted agents.

That is we would could have two constructors like this:

   // For Microsoft hosted agents
    public AzureStageAttribute(
        [CanBeNull] string suffix,
        AzurePipelinesImage image
    {
       // todo: implement this
    }
    
    public AzureStageAttribute(
        [CanBeNull] string suffix,
        string stageName
    {
       // todo: implement this
    }

There are of course some details that need to be ironed out surrounding this, but before investing too much into this I would like to know what you think about the idea?

Is this something you would consider including if I make a PR for this?

This would still not fix the need to control the pool used for which target/job, but I am thinking that would be a possible future step (possibly adding a AzureJobAttribute to set the pool on a job) , if you are at all agreeing to allow for some improvements in this area?

Usage Example

[AzureStage(
    name: "stage_build_stuff",
    displayName: "Build my stuff",
    poolName: "my-self-hosted-agents",
    InvokedTargets = new[] { nameof(Compile) })]

Generated yaml:

stages:
  - stage: stage_build_stuff
    displayName: 'Build my stuff'
    dependsOn: [  ]
    pool:
      name: my-self-hosted-agents
    jobs:
      - job: Restore
      ....

Alternative

No response

Could you help with a pull-request?

Yes