Add Bazel rules for C# packaging, distribution and documentation

farost commented 3 months ago

What is the goal of this PR?

We prepare tools for the C# driver release, namely: documentation, packaging, and distribution.

What are the changes implemented in this PR?

Added: Rules for the C# nuget packages generation and distribution. These rules are based on the rules from the open source Selenium repo, so thanks to them for boosting the development by making it available! They are used and tested in the typedb-driver project:

nuget_pack: gets a list of C# libraries, native libs files (if needed), a template nuget project description, a list of files to include into the package (for example, README or logos), and produces two files: nupkg (nuget package) and snupkg (symbol package for debugging).
nuget_push: receives the result of the previous command and pushes the packages (with their symbols) to the target (snapshot/release) repo.

Updated:

doxygen configuration, previously used solely for C++. Now it's also convenient for C#, so some refactoring and additions happened.

vaticle-bot commented 3 months ago

PR Review Checklist

Do not edit the content of this comment. The PR reviewer should simply update this comment by ticking each review item below, as they get completed.

Trivial Change

[ ] This change is trivial and does not require a code or architecture review.

Code

[x] Packages, classes, and methods have a single domain of responsibility.
[x] Packages, classes, and methods are grouped into cohesive and consistent domain model.
[x] The code is canonical and the minimum required to achieve the goal.
[x] Modules, libraries, and APIs are easy to use, robust (foolproof and not errorprone), and tested.
[x] Logic and naming has clear narrative that communicates the accurate intent and responsibility of each module (e.g. method, class, etc.).
[x] The code is algorithmically efficient and scalable for the whole application.

Architecture

[x] Any required refactoring is completed, and the architecture does not introduce technical debt incidentally.
[x] Any required build and release automations are updated and/or implemented.
[x] Any new components follows a consistent style with respect to the pre-existing codebase.
[x] The architecture intuitively reflects the application domain, and is easy to understand.
[x] The architecture has a well-defined hierarchy of encapsulated components.
[x] The architecture is extensible and scalable.

farost commented 3 months ago

There is a series of connected PRs:

vaticle / bazel-distribution