[feature]: `--no-build` option for KubeOps.Cli

[tillig]

Is your feature request related to a problem? Please describe.

When running the automated code generation, the CLI tool shows that it's rebuilding the assembly that has, presumably, already been built. This can be confusing in a build log or for developers wondering why the same assembly is being compiled twice.

Describe the solution you would like

Add a --no-build option to the KubeOps.Cli that possibly allows a specific assembly to be passed in. Or perhaps allow a precompiled assembly to be passed in rather than a .csproj or .sln file. Make this part of the KubeOps.Operator.targets default behavior - use the assembly that the compiler just finished creating rather than something separately compiled.

Additional Context

No response

[wasabii]

I think, really, the tool should not be using MSBuild at all. Duplicate invocations of MSBuild through secondary processes is always subject to weird random failures.

If the goal of the tool is simply to reflect over some assemblies, it should just do that, and it should be passed the closure through an argument.

[buehler]

I agree @wasabii. The tool was created in the first place to create the necessary configuration files for the operator to deploy them. It kind of "historically grew", as such tools do :-)

I would love to solve those issues with code generators or similar techniques, but currently you cannot generate code inside the source tree as far as I understand. The build is required for the correct reflection though.

If there is a cool alternative for this usecase, we're happy to hear proposals.

[tillig]

I could be misunderstanding, but just looking through the AssemblyLoader for the CLI, it seems the largest challenges are:

• Locate the assembly/assemblies for the application
• Get the potential types from those assemblies that need to generate metadata

I think that should be possible by pointing to a build output location rather than invoking the build directly, yeah? There's some pretty decent documentation on how to inspect assemblies in a standalone MetadataLoadContext as well as a simple example of an assembly resolver.

Agreed that you can't run the tool as it stands against uncompiled code - you'd need an assembly for the load/reflection - but I think it would be possible to make some minor changes to the existing tool to allow it to run against something already built rather than running the build and then running the build a second time from the CLI tool. I could be trivializing the effort due to some complexity I don't understand.

[wasabii]

That's correct. There's a few things I would do, though, to make this a 'complete' solution:

a) Refactor the code as a library.
b) Refactor the code to accept a set of Assemblies for scanning for attributes/etc.
c) Rewrite the CLI implementation to accept the set of reference assemblies on the command line, or a path to a directory of these assemblies (-lib). It is my view that you should not attempt to do discover of the .NET SDK from the CLI itself: it needs to be fed that information. There is no reliable method for discovering this across platforms, etc.
d) Also implement a MSBuild Task that invokes the same library, also taking a path to the assemblies. I personally think this is a better option than invoking the CLI from inside of MSBuild. The output files should be directed to a temp directory in IntermediateOutputPath, and not into the project root itself. And then included as None so they can be bundled into CopyToOutputDirectoryItems. With this target scheduled to run before.

Rely on the existing MSBuild information to pump the closure of ref assemblies to the MSBuild Task. It is the only reliable source of this information at this point in time. Users from the CLI manually should specify either -r: or -lib: to the CLI.

That would be basically three potential inputs for each of the entry paths: ReferenceAssemblies (-r or -lib), and AssembliesToScan (default args). MSBuild would fill these in with its sources.