enable theo11y pack repo to accept contributions

[jpvajda]

Details

The o11y pack repo needs to be setup to facilitate contributions from internal relics for Reli-Hack so we'll want to put in some basic github actions and ensure documentation is clear to facilitate contributions.

Acceptance Criteria

• determine with @kidk what basics checks may be required.
• provide feedback on the documentation and developer exp to @kidk.
• look for basic automation opportunities in the process and implement those checks.
• look for advanced automation opportunities int the process and make a new ticket to implement those checks in a future sprint.
• Define JSON schema for dashboards
• Define JSON schema for alerts
• Define JSON schema for synthetics
• Define overall JSON schema for o11y packs
• Add PR template
• Update contributing guide and include guidance on conventional commits
• Add check for conventional commits on push
• Add check for schema compliance on push

[jpvajda]

@jpvajda I'll take this one.

[jpvajda]

@kidk the DevEn teamed discussed this but it feels a little early to be able to try to attempt to build a pack as the repo seems to be unfinished and we have some pending architecture decisions. what do you think?

[jpvajda]

We discussed today with @kidk and I revised to be more about enable the repo for contributions vs. trying to build a pack.

[aswanson-nr]

@jpvajda / @kidk I'm sure I'm missing some information, but build/deployment seem like hard requirements before we can accept contributions. Otherwise, we have no way to validate the pack.

All that being said, there are a few things we can get started with:

• Update the CONTRIBUTING guide, it looks like we just have the default
• Document that conventional commits should be used (we are using them, right?)
• Add a PR template
• Add a job to verify that all commits are conventional on push
• Add a job to check YAML syntax on push
• Add a job to verify pack structure
  • this might be something that the CLI does, but if the CLI won't be ready then we should add something even if it's pretty basic

[jpvajda]

@aswanson-nr those all sound like actionable steps, let's do it as part of this ticket.

[zstix]

After speaking with @aswanson-nr, I think we have a clear direction on acceptance criteria:

Acceptance Criteria

• Update the CONTRIBUTING guide, it looks like we just have the default
• Document that conventional commits should be used (perhaps part of contributing guide)
• Add a PR template
• Add a pre-commit-hook to verify that all commits are conventional
• Add a job to check that the YAML is valid and has the just currently-defined required fields (listed below)

Minimum Required Configuration (Currently)

• Observability Packs
  • name
  • level (although this might not be necessary - no level could mean community)
• Alerts (if present)
  • name
  • type
  • nrql (if we don't also support apm & synthetics alerts)
• Dashboard (if present)
  • name
• Flex (if present)
  • name
  • integrations (is this required?)
• Synthetics (if present)
  • name
  • type (we should consider adding this for other types (e.g. pings))

[aswanson-nr]

Reopening because the workflow does not run on a forked PR.

[aswanson-nr]

I have confirmed that the workflow behaves properly during a fork PR