Wrong identification of primary repository in some cases

echalone commented 3 years ago

Synopsis

In some cases the first repository checked out in a Yaml pipeline with a multiple repository checkout scenario is wrongly identified as the primary repository. The self repository should instead always be identified as primary repository (if it was checked out).

I would have already fixed the bug and have already created a pull request to the master branch of this repository: https://github.com/microsoft/azure-pipelines-agent/pull/4217 The pull request needs to be reviewed and accepted.

This bug leads to the following wrong behaviours

It is always the repository url of the first repository checked out (instead of the self repository) that gets stored in the repositoryUrl field of the SourceFolder.json configuration file of a pipeline. For example... This:
checkout: self

checkout: MyRepo2

will store the URL of the self repository in the repositoryUrl field of the SourceFolder.json configuration file of the pipeline.
But this:

checkout: MyRepo2

checkout: self


will store the URL of the "MyRepo2" repository in the repositoryUrl field of the SourceFolder.json configuration file of the pipeline, and not as expected the URL of the self repository (as it is the primary repository).

The Build.Repository.LocalPath build variable should (according to the code in the BuildJobExtension.IsCheckoutToCustomPath method) always point to the path of the self repository if a path was defined during checkout, except if it's the default path (say, "s/MyRepo1" for a repository named MyRepo1). That's exactly the case if you check the self repository out first (instead of second or so). And also as soon as you define a path in the checkout step other than its default path, Build.Repository.LocalPath will point to that path. Though if you specifically define the path of the self repository to be the default path (again say "path: s/MyRepo1") and it is NOT the first one being checked out in a multi-checkout szenario, the Build.Repository.LocalPath build variable is suddenly pointing to the path of the self repository (so "s/MyRepo1" in this example). This is inconsistent behaviour, with the value of the Build.Repository.LocalPath build variable being dependent on the checkout position of the self repository in a multi-checkout scenario if (and only if) the default path for the self repository was specified. For example, if the name of the self repository is "MyRepo1" and the name of the MyRepo2 repository is "MyRepo2" then... This:
checkout: self path: s/MyRepo1

checkout: MyRepo2 path: s/MyRepo2

will set the Build.Repository.LocalPath build variable to the default value "$(Pipeline.Workspace)/s".
But this:

checkout: MyRepo2 path: s/MyRepo2

checkout: self path: s/MyRepo1


will set the Build.Repository.LocalPath build variable to the path of the self repository value "$(Pipeline.Workspace)/s/MyRepo1".
While ANY scenario in which the path of the self repository does NOT point to the default path will result in the Build.Repository.LocalPath build variable to point at the self repository path, again showing that the behaviour is intendet to be independent of the positioning of the self repository checkout step.

If you check the self repository out first and to another path than its default path, Build.Repository.LocalPath will point to that path, as expected. But if you then changed the self repository to be the second repository being checked out and let it now specifically check out to the default path (say "s/MyRepo1") by specifying that path during the checkout step, it then doesn't update the Build.Repository.LocalPath variable (on its first run) which is still pointing to the old path (which doesn't even exist any more since the repository was moved). It seems to correct that path on the next run though. For example, if the name of the self repository is "MyRepo1" and the name of the MyRepo2 repository is "MyRepo2" then... This:
checkout: self path: s/CustomPath

checkout: MyRepo2 path: s/MyRepo2

will set the Build.Repository.LocalPath build variable to the path of the self repository, so "$(Pipeline.Workspace)/s/CustomPath" in this case.
And if you afterwards change it to this:

checkout: MyRepo2 path: s/MyRepo2

checkout: self path: s/MyRepo1


the first run will remain to have the Build.Repository.LocalPath build variable point to the old path "$(Pipeline.Workspace)/s/CustomPath", which actually doesn't even exist any more (as the self repository was moved to "$(Pipeline.Workspace)/s/MyRepo1"). On a second run, this will revert itself to the (still wrong) value "$(Pipeline.Workspace)/s/MyRepo1". This value is still wrong, as it should revert to "$(Pipeline.Workspace)/s", see previous point for an explanation why this is wrong.

Agent Version and Platform

Agent Version: v2.189.0 (latest release, bug is in code of current master branch) and below OS of the machine running the agent: Windows (but should be OS independent)

Azure DevOps Type and Version

dev.azure.com and on-premises Azure DevOps Server 2020 onwards. Bug is in agent, not Azure DevOps Server, therefore the bug is independent of the server version or type. However, Azure DevOps Server 2019 and below doesn't allow a multi checkout scenario yet and will therefore not be able to recreate this issue.