microsoft
Skip generation if input yaml hasn't changed and parameters haven't changed
When the tool is integrated with dev workflows (build process & such), significant performance gains on the overall build process can be achieved if kiota NO-OPs. We could hash the yaml + parameters on entry, store this in a local hidden file and compare on next run. AB#9033
Question: where would this 🐱👤 file get stored? Think both windows and not-windows, OS's.
My original thoughts were to create a kiota.lock in the output directory. This way the file could be committed and if multiple developers contribute to the same repo, or for CI, the generation process would not kick again unnecessarily. The alternative I was thinking out would be temp dir + kiota + hash of the output directory. But having magic hidden files is more pain than anything in my experience: when things go wrong and you need to edit it, you need to find it first. I'm curious about your thoughts on the matter?
To be honest - I wasn't sure at all, which was why I was asking the question :)
I was guessing that this would be created in some .kiota folder + file but is not committed to git (it's in the .gitignore file).
But I also like using something like the bin or obj folder(s) because they are already git-ignored.
I always feel uneasy about committing 'temp' stuff into source control.
But there's a major assumption here: when is Kiota executing, to do the parsing?
- Each time
dotnet buildis ran? - Manually when the developer executes some kiota command? like a
dotnet toolordocker run?
This then help me understand when something is to be checked (if exists, don't parse .. else parse).
I don't think we can put this file in bin/obj as the target project might be anything but dotnet (TS/Java at the moment) and getting into the business of "discovering how the target project is setup" will be messy. (those paths can change based on configuration)
I think this feature would be mostly useful in integrated more (on pre-build) but I believe we should design it in a way it provides value to people using the cli from docker/dotnet tool/bianries too.
ah yes, I keep forgetting about not-dotnet langs. Appologies.
Okay - so how about maybe something like this: an argument that defines the cache-output directory =>
- defaults to the current directory the command is getting executed in
- defaults to
.kiota
so this could give people the option to define their own location (if they want to) but has a default starting point which ALSO makes it discoverable pretty early on: "oh waa, what's this .kiota folder here ..."
(me, just thinking out aloud)
yeah providing the option to place the file at a different place (root of the repo for eg instead of output path) makes a lot of sense.
We've spent some time doing some design thinking about that. First the lock file needs to be placed in the output directory. This way multiple people working on the same solution from a repo, would not keep updating and conflicting each other. Second, the hash of the open api doc needs to be done via the object model itself, not for the text file, to avoid regenerating for things like whitespace changes or comment added. We've logged an issue in the openapi lib to add support for that.
First the lock file needs to be placed in the output directory.
Does this mean each language has it's own concept of an output directory and if so .. Kiota needs some "smarts" to know this?
here I was referring to the directory passed as the output option to Kiota, it's going to be the same argument regardless of the language.
yep - same argument (exe is language agnostic) and the value will differ per developer who will decide what to use/set it, at. sweet!
update on this one:
- The "hashing" capability from OpenApi.Net is now available, effectively unblocking us.
- As a first step in the right direction, #1864 adds local caching of descriptions in temp folders to avoid pulling things over the wire each time.