[DependencyUpdater] Allow to run from different organizations

[torbacz]

Description

• Change project owner regex: previously hardcoded "nanoframework", now the project owner is created based on git repository link
• Added parameters for user and usermail
• Added unit tests for regex methods
• Code refactor to reduce nesting

Motivation and Context

• Fixes DependencyUpdater unable to use with different organization than nanoframeowrk Home#1090

How Has This Been Tested?

• Tested with local repository, successfully created PR https://github.com/torbacz/testStyleCopMsBuild/pull/3/commits/136e2f8b8208121b2f316d12a4ab8299d6a21fd1

Screenshots

Types of changes

• Improvement (non-breaking change that improves a feature, code or algorithm)
• Bug fix (non-breaking change which fixes an issue with code or algorithm)
• New feature (non-breaking change which adds functionality to code)
• Breaking change (fix or feature that would cause existing functionality to change)
• Config and build (change in the configuration and build system, has no impact on code or features)
• Dependencies (update dependencies and changes associated, has no impact on code or features)
• Unit Tests (add new Unit Test(s) or improved existing one(s), has no impact on code or features)
• Documentation (changes or updates in the documentation, has no impact on code or features)

Checklist:

• My code follows the code style of this project (only if there are changes in source code).
• My changes require an update to the documentation (there are changes that require the docs website to be updated).
• I have updated the documentation accordingly (the changes require an update on the docs in this repo).
• I have read the CONTRIBUTING document.
• I have tested everything locally and all new and existing tests passed (only if there are changes in source code).
• I have added new tests to cover my changes.

[josesimoes]

Looks OK. Let's have this into production.
A suggestion for future PRs: changes should be atomic. For a number of reasons.

• They can be reverted easily
• They tend to introduce less changes and review it's easier
• The title is honored and clearly describe the changes made.

Ideally this would have made 2 PRs: one for what the title is 😄 and another with the code refactoring (which is welcomed, of course).

[josesimoes]

Running Unit Tests on the pipeline it's mandatory. We're using MSTest on all other repos, but I guess it's OK to use xUnit here.

[torbacz]

I'll migrate to MSTest, better to use one framework.

[torbacz]

New changes:
Migrate to MsTest framework
Added repoOwner to main parameters
Slightly adjusted code to work better with repoOwner parameter

[josesimoes]

@torbacz looks good. Are you planing to add the unit test running on the pipeline, or would you prefer that I handle that?

[torbacz]

@josesimoes
I can do it over the weekend. Few questions:

1. Any special requirements like generating code coverage or just standard run tests?
2. azure-pipelines.yml <- is this a template for building dependecy updater. Looks like it is, but I want to be sure.
3. If this is the file, line 229 looks like a place for tests step?

[josesimoes]

I can do it over the weekend. Few questions:

Brilliant!

• Any special requirements like generating code coverage or just standard run tests?

Let go with just Unit Tests. It's already an improvent.

azure-pipelines.yml <- is this a template for building dependecy updater. Looks like it is, but I want to be sure.

That's the yaml for AZDO and yes, the job for building dependecy updater starts at line 193 (as you've figured it out).

If this is the file, line 229 looks like a place for tests step?

That's the place.

To save you some work: you can find most of the bits for this on yaml template on this repo on a template for the class build.
Check here and here.
That should get you to a good start. 😉

[torbacz]

@josesimoes
Is there something wrong with build agents?

[josesimoes]

@josesimoes Is there something wrong with build agents?

Nothing wrong. Seems that there is an issue with the yaml format... I believe that's because you can't have multiple wildcards in the path. (line 238). You can check the pipeline log if you click on the check above. Here it is:
https://dev.azure.com/nanoframework/tools/_build/results?buildId=34326&view=results

[josesimoes]

@torbacz the pipeline it's happy now!

It's reporting that no code coverage results where found. Please check if that's a matter of path or those not being generated. If needed, just remove that task.

[josesimoes]

And it's also complaining about Parameter 'repoOwner' has no matching param tag in the XML comment for 'Program.Main

[torbacz]

@josesimoes
Yea i noticed that yesterday, but I was too tired to continue working on it.

I missed one step in pipeline to generate valid code coverage report, which is now added, but the tool is missing in you organization. So we can:

1. Install https://marketplace.visualstudio.com/items?itemName=Palmmedia.reportgenerator in you organization and we should get valid code coverage reports with pretty charts. If so it requires admin privileges to set up. Can be done via "Organization settings" -> Extensions -> Browse marketplace page in AZDO.
2. Remove completely code coverage tasks from pipeline.

Let me know, which approach is better for you (But I suggest to create reports, will be easier to maintain project later).

BTW. Pipeline is now failing due to missing reportgenerator@4 task

[torbacz]

Same problem described:
https://stackoverflow.com/questions/60275777/publish-code-coverage-result-failed-in-azuredevops-pipeline

ReportGenerator description:
https://marketplace.visualstudio.com/items?itemName=Palmmedia.reportgenerator

[robin-jones]

Same problem described: https://stackoverflow.com/questions/60275777/publish-code-coverage-result-failed-in-azuredevops-pipeline

ReportGenerator description: https://marketplace.visualstudio.com/items?itemName=Palmmedia.reportgenerator

See here for a (potentially) different way (without needing any plugins). nanoframework/nanoFirmwareFlasher#128

Although looking at the differences, it looks like the summaryFileLocation is not set to the correct directory.

[torbacz]

@robin-jones Yea, you are right. But now it's complaining about multiple reports from one test lib :D One of report generator function is to merge all tests results into one.

@josesimoes It's up to you, which solution is best.

[networkfusion]

@robin-jones Yea, you are right. But now it's complaining about multiple reports from one test lib :D One of report generator function is to merge all tests results into one.

@josesimoes It's up to you, which solution is best.

Sorry to be a pain (same person as last comment, just realised I was logged in with my work account), but can you try this:

https://stackoverflow.com/questions/68919661/azure-net-cobertura-warningmultiple-file-or-directory-matches-were-foun

[networkfusion]

Actually see: https://josh-ops.com/posts/azure-devops-code-coverage/ it can be done via a script instead. I am just trying it on nanoframework/nanoFirmwareFlasher#128

[torbacz]

@networkfusion
Not sure if using custom script rather than AZDO task is better, but it's more complicated. In all of my pipelines im using report generator task to merge them into one.
For sure, we should use the same approach across all repos.

[networkfusion]

We use similar methods for installing the SDK etc. and (if this PR is designed to run on "anyones" repo, it is probably better not to add that external dependency IMHO.

Anyway, I have got it working now: https://github.com/nanoframework/nanoFirmwareFlasher/pull/128/files#diff-7915b9b726a397ae7ba6af7b9703633d21c031ebf21682f3ee7e6a4ec52837a5

[torbacz]

@networkfusion
One more fix to your script and it's good to go :)
888ffef

[networkfusion]

I think I worked that out at the same time as you 😁

[josesimoes]

I ❤️ these pair coding sessions! 🤣

[torbacz]

@networkfusion
Works great now, thanks for help :)
https://dev.azure.com/nanoframework/tools/_build/results?buildId=34361&view=results

@josesimoes
PR should be ready to merge as soon as build finishes.

[josesimoes]

LGTM!

[josesimoes]

@torbacz any chance you can update nanodu github action to take these new parameters and pass them to the tool? 😉

[torbacz]

@josesimoes
Sure.

[josesimoes]

@torbacz after running this on the samples repo, I ended up making a fix the the tool, then run it again and it's working now.

Looking forward to your feedback on how it performs on 3rd party repos!

[torbacz]

Ops, my mistake there. It should be "#if !DEBUG".

Probably I'll work on nanodu this week (problem with custom nuget repositories and authorization) so I'll include this one also.

[josesimoes]

No worries with that block, I believe I have already fixed with my change of today.