shashank-elastic commented 3 weeks ago

Pull Request

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 https://github.com/elastic/detection-rules/pull/4088/

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

[ ] 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

protectionsmachine commented 3 weeks ago

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

[ ] 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 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.

[ ] 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.

[ ] 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 commented 3 weeks ago

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

shashank-elastic commented 2 weeks ago

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.