Proposed RFC Feature: Static Analysis via GitHub Actions

[Kadino]

Summary:

Static Analysis tool(s) could execute during Automated Review OR periodically run and auto-cut issues based on the findings. Static analysis tools exist in GitHub actions, which O3DE has "free" credits for executing as part of being an open source project: https://github.com/marketplace/category/code-quality . Determine which are appropriate to run, and propose the cadence they should run.

TODO: This RFC is a stub, and needs to be further defined before it is ready for comment and further revision. Fill out the sections below, and bring this document to review with SIG-Testing

What is the relevance of this feature?

Why is this important? What are the use cases? What will it do once completed?

Feature design description:

• Explain the design of the feature with enough detail that someone familiar with the environment and framework can understand the concept and explain it to others.

• It should include at least one end-to-end example of how a developer will use it along with specific details, including outlying use cases.

• If there is any new terminology, it should be defined here.

Technical design description:

• Explain the technical portion of the work in enough detail that members can implement the feature.

• Explain any API or process changes required to implement this feature

• This section should relate to the feature design description by reference and explain in greater detail how it makes the feature design examples work.

• This should also provide detailed information on compatibility with different hardware platforms.

What are the advantages of the feature?

• Explain the advantages for someone to use this feature

What are the disadvantages of the feature?

• Explain any disadvantages for someone to use this feature

How will this be implemented or integrated into the O3DE environment?

• Explain how a developer will integrate this into the codebase of O3DE and provide any specific library or technical stack requirements.

Are there any alternatives to this feature?

• Provide any other designs that have been considered. Explain what the impact might be of not doing this.
• If there is any prior art or approaches with other frameworks in the same domain, explain how they may have solved this problem or implemented this feature.

How will users learn this feature?

• Detail how it can be best presented and how it is used as an extension or a standalone tool used with O3DE.
• Explain if and how it may change how individuals would use the platform and if any documentation must be changed or reorganized.
• Explain how it would be taught to new and existing O3DE users.

Are there any open questions?

• What are some of the open questions and potential scenarios that should be considered?

[Kadino]

Some static analyzers appear more focused on security, and some . Need to clarify which aside from CodeQL are useful: https://codeql.github.com/docs/codeql-overview/

[Kadino]

This RFC will need to define how the emitted warnings are tracked and acted upon. Emitting them less than half the story.

[Kadino]

While it remains unclear what the requirements are of a static analysis tool, there is a request for a specific tool in o3de/o3de#10032

[lmbr-pip]

Would be good to cover how this work, if at all, with GitHub code scanning https://docs.github.com/en/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/about-code-scanning

[Kadino]

If SIG-Testing investigates static analysis., be sure to sync with SIG-Build on requirements and recommendations. SIG-Build is looking into enabling static analysis.