Update Kibana MITRE workflow
Pull Request
Issue link(s): Rules Management team has a long running kibana issue that tracks MITRE updates here. So instead of creating a new issue for upgrades, we are modifying the workflow to leave a comment on the existing issue.
Summary - What I changed
- Use https://github.com/peter-evans/create-or-update-comment/tree/v4/ to leave comments on existing issues.
- Latest version is being used and body of the comment is crafted.
How To Test
- Sample Run - https://github.com/elastic/detection-rules/actions/runs/15143731931/job/42574188797?pr=4735
- Sample Comment https://github.com/elastic/kibana/issues/166152#issuecomment-2895242351, typos have been corrected.
Checklist
- [x] Added a label for the type of pr:
bug,enhancement,schema,maintenance,Rule: New,Rule: Deprecation,Rule: Tuning,Hunt: New, orHunt: Tuningso guidelines can be generated - [ ] Added the
meta:rapid-mergelabel 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?
Enhancement - Guidelines
These guidelines serve as a reminder set of considerations when addressing adding a feature to the code.
Documentation and Context
- [ ] Describe the feature enhancement in detail (alternative solutions, description of the solution, etc.) if not already documented in an issue.
- [ ] Include additional context or screenshots.
- [ ] Ensure the enhancement includes necessary updates to the 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 enhancement.
- [ ] Existing unit tests have been updated to reflect the changes.
- [ ] Provide evidence of testing and validating the enhancement (e.g., test logs, screenshots).
- [ ] Validate that any rules affected by the enhancement 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 enhancement does not break existing functionality.
- [ ] Review the enhancement with a peer or team member for additional insights.
- [ ] Verify that the enhancement works across all relevant environments (e.g., different OS versions).
- [ ] Confirm that all dependencies are up-to-date and compatible with the changes.
- [ ] Confirm that the proper version label is applied to the PR
patch,minor,major.
Am running the test here
with GITHUB_TOKEN --> https://github.com/elastic/detection-rules/actions/runs/15141279107 with WRITE_KIBANA_DETECTION_RULES_TOKEN --> https://github.com/elastic/detection-rules/actions/runs/15141096361
Both the token seems to not have access to comment on issues is what i am understanding from resource.
The readme recommends us to use a PAT that has access to the repository do we have one such token for trade-bot? cc @eric-forte-elastic / @Mikaayenson / @traut
Am running the test here
with GITHUB_TOKEN --> https://github.com/elastic/detection-rules/actions/runs/15141279107 with WRITE_KIBANA_DETECTION_RULES_TOKEN --> https://github.com/elastic/detection-rules/actions/runs/15141096361
Both the token seems to not have access to comment on issues is what i am understanding from resource.
The readme recommends us to use a PAT that has access to the repository do we have one such token for trade-bot? cc @eric-forte-elastic / @Mikaayenson / @traut
I think this has to do with the change in this PR to the uses: peter-evans/create-or-update-comment@v4 as writing/creating issues vs comments is the same authentication level (both of which are given to WRITE_KIBANA_DETECTION_RULES_TOKEN)
Have you tried using curl instead of a third party action? E.g. updating the following to comment instead?
curl -X POST \
-H "Authorization: token ${{ secrets.WRITE_KIBANA_DETECTION_RULES_TOKEN }}" \
-H "Accept: application/vnd.github.v3+json" \
https://api.github.com/repos/elastic/kibana/issues \
-d '{
"title": "'"$ISSUE_TITLE"'",
"body": "'"$ISSUE_BODY"'"
}'
I think this has to do with the change in this PR to the
uses: peter-evans/create-or-update-comment@v4as writing/creating issues vs comments is the same authentication level (both of which are given toWRITE_KIBANA_DETECTION_RULES_TOKEN)Have you tried using curl instead of a third party action? E.g. updating the following to comment instead?
curl -X POST \ -H "Authorization: token ${{ secrets.WRITE_KIBANA_DETECTION_RULES_TOKEN }}" \ -H "Accept: application/vnd.github.v3+json" \ https://api.github.com/repos/elastic/kibana/issues \ -d '{ "title": "'"$ISSUE_TITLE"'", "body": "'"$ISSUE_BODY"'" }'
We could shift to CURL i don't see any issues, wanted to use something that is already prevailing in marketplace. Will test CURL and update accordingly.
The above curl is for creating an issue. Am more focused on creating a comment and we can go with the sample below
curl -L \
-X POST \
-H "Accept: application/vnd.github+json" \
-H "Authorization: Bearer <YOUR-TOKEN>" \
-H "X-GitHub-Api-Version: 2022-11-28" \
https://api.github.com/repos/OWNER/REPO/issues/ISSUE_NUMBER/comments \
-d '{"body":"Me too"}'
From reference docs - https://docs.github.com/en/rest/issues/comments?apiVersion=2022-11-28#create-an-issue-comment
I think this has to do with the change in this PR to the
uses: peter-evans/create-or-update-comment@v4as writing/creating issues vs comments is the same authentication level (both of which are given toWRITE_KIBANA_DETECTION_RULES_TOKEN) Have you tried using curl instead of a third party action? E.g. updating the following to comment instead?curl -X POST \ -H "Authorization: token ${{ secrets.WRITE_KIBANA_DETECTION_RULES_TOKEN }}" \ -H "Accept: application/vnd.github.v3+json" \ https://api.github.com/repos/elastic/kibana/issues \ -d '{ "title": "'"$ISSUE_TITLE"'", "body": "'"$ISSUE_BODY"'" }'We could shift to CURL i don't see any issues, wanted to use something that is already prevailing in marketplace. Will test CURL and update accordingly.
The above curl is for creating an issue. Am more focused on creating a comment and we can go with the sample below
curl -L \ -X POST \ -H "Accept: application/vnd.github+json" \ -H "Authorization: Bearer <YOUR-TOKEN>" \ -H "X-GitHub-Api-Version: 2022-11-28" \ https://api.github.com/repos/OWNER/REPO/issues/ISSUE_NUMBER/comments \ -d '{"body":"Me too"}'From reference docs - https://docs.github.com/en/rest/issues/comments?apiVersion=2022-11-28#create-an-issue-comment
Yes, the curl I sent was from the original workflow to illustrate how this PR shifts the existing approach; going from a low dependency method, to a high dependency method. It was not meant as instruction on the correct curl call to use. Did the curl approach work with the token in the workflow, or is there still an issue for the token?
Yes, the curl I sent was from the original workflow to illustrate how this PR shifts the existing approach; going from a low dependency method, to a high dependency method. It was not meant as instruction on the correct curl call to use. Did the curl approach work with the token in the workflow, or is there still an issue for the token?
The CURL approach works fine