Skip to content

Bugfixing primary repository detection #4217

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

echalone
Copy link
Contributor

This is a new pull request replacing the old pull request #3473 which included two changes. Both these changes of the old pull request have been splitted up according to the suggestion by @ismayilov-ismayil (the other new pull request being #4216). This pull request contains the primary repository detection problem fixes. It also already contains the change of the "Find" to the "FirstOrDefault" calls on the Repositories lists as suggested by @Roman-Shchukin in the old pull request.

Bug fixed:

Assignment of primary repository fixed

The setting of the RepositoryUtil.IsPrimaryRepository flag for the primary repository was not implemented correctly. It was always set for the repository that is first checked out. Now while this will normaly be the self repository, it doesn't have to be. In fact, if you really need to know the first repository that has been checked out, that information has its own job-flag/property called WellKnownJobSettings.FirstRepositoryCheckedOut. If the self repository is checked out as the second repository it should still be marked as the primary repository. The RepositoryUtil.IsPrimaryRepositoryName method shows the way here, always looking for the repository with alias "self", therefore clearly stating that the self repository is the primary repository. However, the RepositoryUtil.GetPrimaryRepository first uses the RepositoryUtil.IsPrimaryRepository flag to check for the primary repository and only if it doesn't find it set for any repository will look for the repository with the alias "self". So if the wrong repository has been set the IsPrimaryRepositoryName flag the RepositoryUtil.GetPrimaryRepository method will return the wrong repository. And the result of the RepositoryUtil.GetPrimaryRepository method and the RepositoryUtil.IsPrimaryRepositoryName method will not be consinstent though they should clearly provide they same kind of information according to their name.

This bug lead to some strange behaviour, for example:

  • The wrong repositoryUrl was saved in the trackingConfig/SourceFolder.json (not the one for the self repository, but the one for the repository that gets checked out first)
  • Build.Repository.LocalPath 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/MyRepo" for MyRepo). That's exactly the case if you check the self repository out as the first repository (instead of the second or so). As soon as you define a path in the checkout step other than its default path, Build.Repository.LocalPath points to that path. Though if you specifically define the path of the self repository to be the default path (again say "path: s/MyRepo") and it it NOT the first one being checked out in a multi-checkout szenario, Build.Repository.LocalPath was suddenly pointing to the path of the self repository (so "s/MyRepo" in this example). This inconsistent behaviour is also fixed with this bugfix and if the checkout step for the self repository has the default path specified the build variable Build.Repository.LocalPath will always point to the default source directory path ("s"), no matter if it was checked out as the first repository or not.
  • 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/MyRepo") by specifying that path during the checkout step, it then didn't update the Build.Repository.LocalPath variable (on its first run) which was 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. That behaviour is now also fixed with this bugfix.

I added UnitTests to test for the correct setting of the RepositoryUtil.IsPrimaryRepository flag in the future, even under circumstances which resulted in the wrong repository with this flag set in the past.
I also added UnitTests to test for the correct effects of this flag on the tracking configuration and Build.Repository.LocalPath build variable.

@ismayilov-ismayil
Copy link
Contributor

/azp run

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@ismayilov-ismayil
Copy link
Contributor

Tested with multiple repositories and check result without this change - sometime the primary/first repo is different than expected.
Tested with this change - each time the primary/first repo is what expcected.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants