Adding ability to make async calls in Gauge tests

[mpekurny]

Create ability to make async calls from Gauge tests. This also changes how the grpc calls are created and handled to allow for more DI and starting with an async handler to carry that through to the reflection call to the Gauge step or hook.

[mpekurny]

@chadlwilson the checks above are failing with the following errors

Error: getgauge/setup-gauge/master/action.yml (Line: 30, Col: 7): Unexpected value 'using' Error: getgauge/setup-gauge/master/action.yml (Line: 31, Col: 7): Unexpected value 'main' Error: getgauge/setup-gauge/master/action.yml (Line: 29, Col: 7): There's not enough info to determine what you meant. Add one of these properties: run, shell, uses, with, working-directory Error: getgauge/setup-gauge/master/action.yml (Line: 17, Col: 11): Unrecognized named-value: 'gauge-version'. Located at position 1 within expression: gauge-version == 'master' Error: getgauge/setup-gauge/master/action.yml (Line: 24, Col: 11): Unrecognized named-value: 'gauge-version'. Located at position 1 within expression: gauge-version == 'master' Error: System.ArgumentException: Unexpected type '' encountered while reading 'steps item uses'. The type 'StringToken' was expected.

I see you made a change in the setup-gauge repo, I am thinking your change is the cause of the errors above?

[chadlwilson]

Yeah, I'll fix it or revert shortly. No idea why these things all work off master, makes it impossible to validate anything safely.

As a side note, I'm not sure it's realistic to expect anyone to review a PR with 50,000 line changes?

[mpekurny]

Yeah, I get that it was a lot of changes. Maybe I could have broken up some of the changes into smaller chunks. I will keep that in mind if I ever do something like this again.

[sriv]

It was a big changeset, but it brought in an important feature. Most changes were due to formatting and reorg of code.

the big ones were around the launch of grpc server using WebBuilder, use of DI as opposed to hand rolled injections, some modern c# features like the usings.cs and move executors to a separate namespace. And of course the biggest deal was to make the entire flow async, so that tests with async fit in better. All good changes I believe.

Thanks a lot for the effort @mpekurny - really appreciate the work and attention to details here.

[gaugebot]

@mpekurny Thank you for contributing to gauge-dotnet. Your pull request has been labeled as a release candidate 🎉🎉.

Merging this PR will trigger a release.

Please bump up the version as part of this PR.

Instructions to bump the version can found at CONTRIBUTING.md

If the CONTRIBUTING.md file does not exist or does not include instructions about bumping up the version, please looks previous commits in git history to see what changes need to be done.

[sriv]

this is required for an offline gauge --init dotnet command. i.e. when gauge cannot reach the template directory

[mpekurny]

Would it be possible to include the zip file in the plugin distribution and unzip it in offline mode? It seems a duplicate effort to have to maintain the code in the template directory and have to include the text of the source code in the template directory here.

[mpekurny]

@sriv

To rephrase my previous comment a little, I know it's "possible" to do this, I am more wondering about your opinion on should we go in that direction. On the one hand, it would cut down on developer work when updating .NET versions. On the other hand, including the zip in the plugin would make the plugin download significantly bigger. I'm not sure about the tradeoff.

[sriv]

alright, I am going to be a bit adventurous here and state that we ditch offline init for now and we can bring that back in if someone has a genuine need for it (although I doubt it since there is nothing in the seed project that can be of any practical use beyond taking gauge for a quick trial)

[sriv]

Gauge.CSharp.Core was inlined here aas part of #210 because this was the only project that uses it. Earlier we used to have Gauge Visual Studio plugin which is now deprecated, maintaining another repo hurt a bit of dev experience when changing across components

[mpekurny]

@sriv

I'm not sure what you need me to do here? The Gauge.CSharp.Core folder had three types of files.

The first type was the generated classes for the grpc models and interfaces to the grpc server. My changes create those files now at build time so they are always in sync with the protobuf submodule.

The second type was a set of TCP/Connection classes that I could not find used anywhere. Maybe they were necessary for the now deprecated Visual Studio plugin? I could certainly bring them back if they are used for some purpose, but I searched for any of of them and couldn't find anything.

The third "type" of file was the Utils class which was a set of static methods for reading environment variables. This functionality has been moved to the IConfigurationExtensions class in the extensions folder.

[sriv]

TCP connection classes are a bit outdated since older versions of gauge did not do gRPC. They were hand rolled RPC mechanism with proto contracts. These classes were to make the dotnet runner compatible with older gauge versions.

But coming to think of it, these versions are years old and I think we just let go of the legacy and use gRPC as the default now. Users running older version of gauge would need to use a compatible dotnet runner version.

[sriv]

Just realized couple of things:

• removing the IGaugeCommand and relevant classes basically removes the ability to init a gauge project in an offline mode.
• Gauge.CSharp.Core was inlined here as part of Programmatic skip scenario #210 -the reason was that this is the only consumer left for that library and it seemed to help the development by cutting down on the steps required to make a contract change.

[sriv]

Thanks again @mpekurny - this was quite a bit of work, but a good milestone for gauge-dotnet!