kiota icon indicating copy to clipboard operation
kiota copied to clipboard

Cannot run via Docker on M1 Mac

Open dabernathy89 opened this issue 3 years ago • 1 comments

The command I'm running:

docker run --platform linux/amd64 -v ~/code/kiota-test/output:/app/output mcr.microsoft.com/openapi/kiota generate --language typescript -n PetsSdk --openapi https://petstore3.swagger.io/api/v3/openapi.json

The output:

Unhandled exception: System.IO.IOException: Function not implemented
   at System.IO.FileSystemWatcher.StartRaisingEvents()
   at System.IO.FileSystemWatcher.StartRaisingEventsIfNotDisposed()
   at System.IO.FileSystemWatcher.set_EnableRaisingEvents(Boolean value)
   at Microsoft.Extensions.FileProviders.Physical.PhysicalFilesWatcher.TryEnableFileSystemWatcher()
   at Microsoft.Extensions.FileProviders.Physical.PhysicalFilesWatcher.CreateFileChangeToken(String filter)
   at Microsoft.Extensions.FileProviders.PhysicalFileProvider.Watch(String filter)
   at Microsoft.Extensions.Configuration.FileConfigurationProvider.<.ctor>b__1_0()
   at Microsoft.Extensions.Primitives.ChangeToken.ChangeTokenRegistration`1..ctor(Func`1 changeTokenProducer, Action`1 changeTokenConsumer, TState state)
   at Microsoft.Extensions.Primitives.ChangeToken.OnChange(Func`1 changeTokenProducer, Action changeTokenConsumer)
   at Microsoft.Extensions.Configuration.FileConfigurationProvider..ctor(FileConfigurationSource source)
   at Microsoft.Extensions.Configuration.Json.JsonConfigurationProvider..ctor(JsonConfigurationSource source)
   at Microsoft.Extensions.Configuration.Json.JsonConfigurationSource.Build(IConfigurationBuilder builder)
   at Microsoft.Extensions.Configuration.ConfigurationBuilder.Build()
   at kiota.Handlers.BaseKiotaCommandHandler.<>c.<.ctor>b__23_0() in /app/kiota/src/kiota/Handlers/BaseKiotaCommandHandler.cs:line 21
   at System.Lazy`1.ViaFactory(LazyThreadSafetyMode mode)
   at System.Lazy`1.ExecutionAndPublication(LazyHelper executionAndPublication, Boolean useDefaultConstructor)
   at System.Lazy`1.CreateValue()
   at System.Lazy`1.get_Value()
   at kiota.Handlers.BaseKiotaCommandHandler.get_Configuration() in /app/kiota/src/kiota/Handlers/BaseKiotaCommandHandler.cs:line 18
   at kiota.Handlers.KiotaGenerationCommandHandler.AssignIfNotNullOrEmpty(String input, Action`2 assignment) in /app/kiota/src/kiota/Handlers/KiotaGenerationCommandHandler.cs:line 95
   at kiota.Handlers.KiotaGenerationCommandHandler.InvokeAsync(InvocationContext context) in /app/kiota/src/kiota/Handlers/KiotaGenerationCommandHandler.cs:line 48
   at System.CommandLine.Invocation.InvocationPipeline.<>c__DisplayClass4_0.<<BuildInvocationChain>b__0>d.MoveNext()
--- End of stack trace from previous location ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c__DisplayClass17_0.<<UseParseErrorReporting>b__0>d.MoveNext()
--- End of stack trace from previous location ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c__DisplayClass12_0.<<UseHelp>b__0>d.MoveNext()
--- End of stack trace from previous location ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c__DisplayClass22_0.<<UseVersionOption>b__0>d.MoveNext()
--- End of stack trace from previous location ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c__DisplayClass19_0.<<UseTypoCorrections>b__0>d.MoveNext()
--- End of stack trace from previous location ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c.<<UseSuggestDirective>b__18_0>d.MoveNext()
--- End of stack trace from previous location ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c__DisplayClass16_0.<<UseParseDirective>b__0>d.MoveNext()
--- End of stack trace from previous location ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c.<<RegisterWithDotnetSuggest>b__5_0>d.MoveNext()
--- End of stack trace from previous location ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c__DisplayClass8_0.<<UseExceptionHandler>b__0>d.MoveNext()

dabernathy89 avatar Oct 14 '22 21:10 dabernathy89

Hi @dabernathy89, Thanks for trying out Kiota and for letting us know. Unfortunately, I don't have access to an M1 machine to run some tests, so if you're willing to help diagnose and solve this issue, it'd be greatly appreciated.

The dockerfile is located here, and the issue is most likely triggered by the reload on change setting here

My suggestion for you would be to set the value to false/remove it, build the image locally and see whether that solves the issue. I don't think we need reload on change enabled since Kiota is a CLI and all processes are short lived anyway. If that works, would you be so kind to submit a pull request with the change please?

Thanks a lot!

baywet avatar Oct 16 '22 07:10 baywet

This issue has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for 4 days. It will be closed if no further activity occurs within 3 days of this comment.

ghost avatar Oct 20 '22 08:10 ghost

Reopening this as it seems this is still an issue from internal feedback. Yes disabling the reload on change helps (and we don't need it anyway), but it's not enough.

We also need to setup a multi-platform build of the image https://docs.docker.com/build/building/multi-platform/ Additionally, when running in a container with the --co switch, we should alter the target path to delete the content of the directory, not the directly itself (locked because mapped).

crit: Kiota.Builder.KiotaBuilder[0]
      error generating the client: Could not open/create output directory /app/./output, reason: Device or resource busy : '/app/output'

baywet avatar Nov 08 '22 17:11 baywet

update: I have put a PR together to remove the barriers as well as enable multi-platform images. Before I merge it, if somebody with an M1 could try to run ghcr.io/baywet/kiota:latest and provide feedback here, it'd help.

baywet avatar Nov 09 '22 18:11 baywet

Update: thanks to @kevinswiber 's help it seems that we're affected by this, and it's because the base dotnet image is not a true arm64 variant

The solution would be to either downgrade to net6 with all the compatibility and performance implications (new linq methods, vectorialization, etc...) or conditionally build on with a different base

more resources: https://www.docker.com/blog/multi-arch-build-and-images-the-simple-way/

baywet avatar Dec 30 '22 14:12 baywet

update: @kevinswiber was instrumental to finding the solution to this issue. Just merged the corresponding PR, releasing soon. :)

baywet avatar Jan 04 '23 18:01 baywet