You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
For a while now, we've known that we need an RFC (or two) which will cover the following topics:
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.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).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.
The text was updated successfully, but these errors were encountered: