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

RFC NEEDED: C++ API reference generation and coverage chart #50

Open
sptramer opened this issue Aug 1, 2022 · 1 comment
Open

RFC NEEDED: C++ API reference generation and coverage chart #50

sptramer opened this issue Aug 1, 2022 · 1 comment
Labels
rfc-needed RFCs which have no draft, but are known to be needed

Comments

@sptramer
Copy link
Contributor

sptramer commented Aug 1, 2022

For a while now, we've known that we need an RFC (or two) which will cover the following topics:

  • Being able to automatically create API reference generation from O3DE source - this is currently a manual process using external files from the o3de repo, and @sptramer has some notes and ideas on how it could work best with O3DE, but not enough time for a full RFC.
  • Publishing API reference updates to development on a regular cadence. RFC to provide details. Publishing for releases can still be a manual process (but should be as automated as possible, as described).
  • Generating lcov (or similar) API coverage information for the feature grid, as well as suggested metrics for hitting YELLOW and GREEN. These suggestions will need to be approved by the TSC. @lmbr-pip has some background and details on this, as he's generated some internal lcov information for sig-networking engineers.

Undoubtedly there is more to consider! Please leave a comment or begin a pre-RFC discussion on the forums if you're interested in helping with this process.

@ShaunaGordon
Copy link
Contributor

For reference purposes...

I've been toying around with Hugo modules and the API docs. As it stands, they make it hard to manage any PR that includes them, because of the sheer volume. As a solution to this, we can pull the API docs out and into their own repository, then use Hugo's module feature (which is an extension of Go modules) to bring them in at deployment time. This also allows us to automate not only the docs generation, but also its updating on Github. We can also reference it at specific tags, so the matching docs version freezes at the right API docs.

Not only does this make automating API docs generation easier, it also dramatically cleans up the website repo, making it less daunting for new contributors.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
rfc-needed RFCs which have no draft, but are known to be needed
Projects
Status: Backlog
Development

No branches or pull requests

2 participants