Skip to content
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

Missing CI script #5

Open
mrtristan opened this issue Feb 16, 2021 · 10 comments
Open

Missing CI script #5

mrtristan opened this issue Feb 16, 2021 · 10 comments

Comments

@mrtristan
Copy link

@ericmargules
Any possibility of exposing the script that's being used to package this library? I found that there's some deadlocking going on and was going to PR a fix for that but without having insight in to how this is packaged it's a little tricky to replace and test existing implementations of this library without dramatically altering it

@ericmargules
Copy link

Hey @mrtristan, thanks for reaching out. This SDK is packaged using a simple NuGet pack command on the command line. Unless I'm misunderstanding your question. Don't hesitate to reach out for more clarification.

@mrtristan
Copy link
Author

@ericmargules

Thanks for the quick response. I can provide more detail shortly when I can get back to a computer but what's on nuget has a different signature and name and such vs what's here. It's almost as if there's another solution that's wrapping things that's not in git. When I ran a dotnet pack on the csproj in here it also seemed like it missed the other src folder of classes.

The dependencies of the two things I was comparing were slightly off too. Something is also bringing in xunit as a dependency of what's on nuget which doesn't seem correct as that's not likely a runtime dependency of the sdk

@ericmargules
Copy link

@mrtristan I'll be pushing up the latest version tomorrow (1.10.0). I'll take another look then and get back to you

@mrtristan
Copy link
Author

@ericmargules ok cool. take a look at this then, perhaps it's low-risk and such enough to be included in that release.

#6

Basically, just trying to get away from the .Result to avoid potential deadlocking. Note this may solve the other issue in this repo.

@iant-ee
Copy link

iant-ee commented Aug 10, 2021

@ericmargules I'd also like to understand a bit more about how this repository is maintained. It looks like it's all generated using a tool and you're the committing the output of that tool?

Unfortunately the Gateway.cs file that that tool is generating doesn't work. We've worked around that by creating our own copy of that file and manually fixing the methods (see #2 - it's the same fundamental problem that @mrtristan is trying to fix). I imagine a small fix in the input when you're generating that file would fix the problem for good.

@iant-ee
Copy link

iant-ee commented Aug 10, 2021

@ericmargules
Copy link

Hey @iant-ee,

Thanks for reaching out. You're correct. It's generated using the OpenAPIGenerator tool with the ExternalYAML produced by the First Data's IPG team.

@iant-ee
Copy link

iant-ee commented Aug 10, 2021

Thanks Eric. Is the ExternalYAML published anywhere? Or anywhere with instructions that would let me generate the code in this repo on my own computer?

@ericmargules
Copy link

Hi @iant-ee,

I'm looking into whether it is published publicly. I'll get back to you shortly. The generation is pretty straightforward. I believe there are some good instructions on their website: https://openapi-generator.tech/

@ericmargules
Copy link

@iant-ee sorry for the delay. I'm found that there isn't a public facing url where you can access this External YAML file, so I'm going to include it in the next release of this library. You should be able to pull it down from there.

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

No branches or pull requests

3 participants