Add flag to update the docs/ATT&CK-coverage.md with markdown URL(s)

[shashank-elastic]

Pull Request

Issue link(s): #4007

Summary - What I changed

• Add a flag --update-coverage to update the markdown links in docs/ATT&CK-coverage.md

• Currently I have used my GIST to test this, changes to docs/ATT&CK-coverage.md should be reverted before merging.

• To Discuss / Design

  • We now build navigators on each push to main.
  • How do we want to update the file, as this will be a commit and on push to main there will be new commits added and i sense this can cause issues and we dont want to be committing so frequently as well?
  • Should we want to build off latest main regularly and update, Like a workflow to execute on Sunday
  • Should this be a prerequisite for a release process?

• Preliminary discussion with Mika

  • A new workflow is warranted and is a great idea to get these changes into main.
  • As opposed to a weekly schedule, we will have this as part of the release process and run this before lock versions.
  • The first run will definitely have changes, progressively any additions or deletions delta will only be updated.

• Code review to be done based on the above deploy model as well.

How To Test

• Currently locally we have run it against my GIST
• All the changes can be seen in docs/ATT&CK-coverage.md which should be reverted before merging!
• We ran a test run of the workflow on PR runs - https://github.com/elastic/detection-rules/actions/runs/10921597672
• A neat PR was created as part of the testing [[ DO NOTY MERGE ]] Update ATT&CK coverage URL(s) in docs/ATT&CK-coverage.md #4088

Workflow Testing After upgrading peter-evans/create-pull-request to v7.0.3

• Workflow Action - https://github.com/elastic/detection-rules/actions/runs/10940282780/job/30372354044?pr=4077
• PR Created - [[DO NOT MERGE ]] Update ATT&CK coverage URL(s) in docs/ATT&CK-coverage.md #4090

Checklist

• Added a label for the type of pr: bug, enhancement, schema, Rule: New, Rule: Deprecation, Rule: Tuning, Hunt: New, or Hunt: Tuning so guidelines can be generated
• Added the meta:rapid-merge label if planning to merge within 24 hours
• Secret and sensitive material has been managed correctly
• Automated testing was updated or added to match the most common scenarios
• Documentation and comments were added for features that require explanation

Contributor checklist

• Have you signed the contributor license agreement?
• Have you followed the contributor guidelines?

[protectionsmachine]

Bug - Guidelines

These guidelines serve as a reminder set of considerations when addressing a bug in the code.

Documentation and Context

• Provide detailed documentation (description, screenshots, reproducing the bug, etc.) of the bug if not already documented in an issue.
• Include additional context or details about the problem.
• Ensure the fix includes necessary updates to the release documentation and versioning.

Code Standards and Practices

• Code follows established design patterns within the repo and avoids duplication.
• Code changes do not introduce new warnings or errors.
• Variables and functions are well-named and descriptive.
• Any unnecessary / commented-out code is removed.
• Ensure that the code is modular and reusable where applicable.
• Check for proper exception handling and messaging.

Testing

• New unit tests have been added to cover the bug fix or edge cases.
• Existing unit tests have been updated to reflect the changes.
• Provide evidence of testing and detecting the bug fix (e.g., test logs, screenshots).
• Validate that any rules affected by the bug are correctly updated.
• Ensure that performance is not negatively impacted by the changes.
• Verify that any release artifacts are properly generated and tested.

Additional Checks

• Ensure that the bug fix does not break existing functionality.
• Review the bug fix with a peer or team member for additional insights.
• Verify that the bug fix works across all relevant environments (e.g., different OS versions).
• Confirm that all dependencies are up-to-date and compatible with the changes.

[shashank-elastic]

Please note we need to decide the deployment model for this before merging, but the code can be reviewed

[shashank-elastic]

Please note we need to decide the deployment model for this before merging, but the code can be reviewed

The deployment model is the workflow file to be run as part of the release process.

[eric-forte-elastic]

🟢 Manual review, looks good to me! 👍