search

getgauge / gauge-dotnet

C# runner for gauge + DotNet standard 6.0-8.0
Apache License 2.0
27 stars 21 forks source link

Add step parameters to the execution Context #211

Closed PiotrNestor closed 3 months ago

PiotrNestor commented 4 months ago

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

PiotrNestor commented 4 months ago

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

jensakejohansson commented 3 months ago

@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: https://github.com/getgauge/gauge-csharp-lib/pull/43 but we cannot make this PR work until it's released. If I remember correctly..

@chadlwilson or can you help out here? :)

chadlwilson commented 3 months ago

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 commented 3 months ago

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.

PiotrNestor commented 3 months ago

@sriv Can you re-run the PR build ...

chadlwilson commented 3 months ago

One of the tests is still failing.

chadlwilson commented 3 months ago

@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 commented 3 months ago

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

chadlwilson commented 3 months ago

@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 commented 3 months ago

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 commented 3 months ago

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 commented 3 months ago

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

chadlwilson commented 3 months ago

Hmm, I'm not sure what is going on now. The tests are still failing despite https://github.com/getgauge/gauge-tests/commit/f3337fa7ca06da7a1b47e3cfb55bacfac4576b4b so I guess I've done something wrong.

chadlwilson commented 3 months ago

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[bot] commented 3 months ago

@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 commented 3 months ago

@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::

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 commented 3 months ago

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

sriv commented 3 months ago

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 commented 3 months ago

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 commented 3 months ago

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.