Add step parameters to the execution Context

[PiotrNestor]

@sriv
Add step parameters data to the execution Context
In hook methods it's possible to access step parameters.

[PiotrNestor]

@sriv
https://www.nuget.org/packages/Gauge.CSharp.Lib#versions-body-tab
At what point will version 0.10.3 be available?

[jensakejohansson]

@sriv
Can you make new release of the Lib so that these changes will work?

https://github.com/getgauge/gauge-csharp-lib/actions/workflows/release.yml
The changes was merged to the lib:
getgauge/gauge-csharp-lib#43
but we cannot make this PR work until it's released. If I remember correctly..

@chadlwilson or can you help out here? :)

[chadlwilson]

I have not followed any of these changes and unfortunately don't really understand the coupling of all the changes here, nor have time to figure it out.

None of the PRs seem to document expected forward/backward compatibility, any required ordering/releases, or any such testing/analysis being done - so it's a bit too much work for me sorry, since I do not work with gauge-dotnet.

[sriv]

apologies again (this is becoming embarrassingly habitual for me).

i just triggered a release (not sure why it did not automatically push to nuget on merge) - https://github.com/getgauge/gauge-csharp-lib/actions/runs/10388824361/job/28765357599

the new version should be out shortly

update - https://www.nuget.org/packages/Gauge.CSharp.Lib/0.10.3 is out and is indexing, should be available in feeds once that is done.

[chadlwilson]

@PiotrNestor Could you please rebase off master when you take a look at the failing test? Your current branch base will definitely fail the LSP tests until rebased.

Also please sign your commits when you rebase. 🙏

(Edit: Looks like you just signed commits, but still needs a rebase)

[PiotrNestor]

@sriv
Are the FTs using the new Gauge.CSharp.Lib 0.10.3
Is that the reason for FTs failing??

[chadlwilson]

@sriv Are the FTs using the new Gauge.CSharp.Lib 0.10.3 Is that the reason for FTs failing??

I'm not sure what you mean here?

The functional tests install latest gauge from master along with building and installing the plugin (from source) off the relevant branch and then run the tests, so if your PR change bumps the required version of Gauge.CSharp.Lib to 0.10.3 it should be using that, yes?

[sriv]

Gauge FTs cache the nuget packages to help speedup the test. And they are currently using 0.10.0 - https://github.com/getgauge/gauge-tests/tree/master/resources/LocalNuget

This should be bumped up. I am away from my computer, so if someone else can do this I'd appreciate it.

[chadlwilson]

Gauge FTs cache the nuget packages to help speedup the test. And they are currently using 0.10.0 - https://github.com/getgauge/gauge-tests/tree/master/resources/LocalNuget

This should be bumped up. I am away from my computer, so if someone else can do this I'd appreciate it.

Oh, ok, that's odd - doesn't seem so great for predictability (GHA caches could achieve the same probably). I'll take a look.

[chadlwilson]

Done so now; am sanity checking off master to check the lib is backwards compatible.

[chadlwilson]

Hmm, I'm not sure what is going on now. The tests are still failing despite getgauge/gauge-tests@f3337fa so I guess I've done something wrong.

[chadlwilson]

Anyway, sorry I got stuck here - not sure I know what I am doing or how to figure out which library versions the tests are actually using.

Don't really understand what would need to be sped up here, as the plugin zip contains the same/correct gauge.csharp.lib dll when it is installed from source. Not sure where FluentAssertions is needed though?

adding: bin/net8.0/Gauge.CSharp.Lib.dll (deflated 55%)

But neither am I share where it is getting the incorrect version from now to end up with

               Error Message: Constructor on type 'Gauge.CSharp.Lib.ExecutionContext+StepDetails' not found.
                Stacktrace: 
                   at System.RuntimeType.CreateInstanceImpl(BindingFlags bindingAttr, Binder binder, Object[] args, CultureInfo culture)
                   at Gauge.Dotnet.Wrappers.ActivatorWrapper.CreateInstance(Type t, Object[] args) in /home/runner/work/gauge-dotnet/gauge-dotnet/src/Wrappers/ActivatorWrapper.cs:line 16
                   at Gauge.Dotnet.ExecutionInfoMapper.StepFrom(StepInfo currentStep) in /home/runner/work/gauge-dotnet/gauge-dotnet/src/ExecutionInfoMapper.cs:line 89
                   at Gauge.Dotnet.ExecutionInfoMapper.ExecutionContextFrom(ExecutionInfo currentExecutionInfo) in /home/runner/work/gauge-dotnet/gauge-dotnet/src/ExecutionInfoMapper.cs:line 38
                   at Gauge.Dotnet.HookExecutor.Execute(String hookType, IHooksStrategy strategy, IList`1 applicableTags, ExecutionInfo info) in /home/runner/work/gauge-dotnet/gauge-dotnet/src/HookExecutor.cs:line 49

[gaugebot]

@PiotrNestor 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]

@chadlwilson

Don't really understand what would need to be sped up here

Gauge dotnet projects do not use the lib from the plugins install location since they come in from the package manager (nuget). Similar to maven central for java or rubygems for ruby. The thing with dotnet is that it does a dotnet restore and then dotnet build to build the test project. There was some rate limiting that we noticed in nuget.org that would prevent the libs from getting installed and with FTs there is a new gauge project initialized and seeded for each functionality. It was in the order of 2-3x of gauge-java FTs, this caching helped bring it to a similar time.

The tests are passing now, the problem was that the gauge-dotnet template was bringing in the older version of Lib.

Some points to note::

• nuget deps have to be pinned to a specific version, there isnt a way (AFAIK) to set it to latest or even 0.10.* to have a wider range support.
• this causes the need for the FT cache and the template to be updated manually.

Happy to hear thoughts on how to make this less painful/cumbersome.

@PiotrNestor - please let me know when this is goo to merge. The FTs are passing and I see that the versions are bumped up as well but I think this can be a 0.6.0release. Also GH thinks there are potential conflicts.

[chadlwilson]

@sriv thanks! Where was the template that needed to be updated?

[sriv]

The templates are a separate repo with the convention - https://github.com/template-. In this case its at https://github.com/getgauge/template-dotnet/

[chadlwilson]

Ahh OK, yeah, I was trying to find where it was loading stuff from and could not figure out that dynamic reference. I don't have permissions to that repository anyway, so wouldn't have been able to fix it in any case :-)

[chadlwilson]

Please take a look at the other requested changes/comments - as there are some confusing changes that don't seem relevant to the PR?

I'd make them myself, but you seem to have prevented maintainers from changing your branch when raising the PR.