a8c-ci-toolkit-buildkite-plugin
a8c-ci-toolkit-buildkite-plugin copied to clipboard
[Docs] Start adding documentation as script headers
[!WARNING] ⚠️ The content of this PR is entirely generated by Cursor—based on the rules and guidance provided by
.cursor/rules/*.mdcabout how we should document our shell scripts.I have quickly skimmed the generated documentation and changes it made (mostly improvements on finer-grained error handling), but this definitively needs a deeper review and closer look at the changes from a human.
- Let Cursor generate initial documentation (part 1)
- Let Cursor generate doc for Android helper scripts
- Cursor Doc for install_npm_packages
WIP
This is WIP as I've stopped the process after Cursor have updated a good set of initial group of scripts, so that it wouldn't become too much of a time sink on my day.
Even if I'm keeping it as Draft until it's properly reviewed, I've still added the team as reviewer of this PR already, so that we can start have some humans taking a deeper look at the changes it generated.
We could continue asking Cursor to work on the remaining script in a follow-up iteration.
| 2 Warnings | |
|---|---|
| :warning: | Please add an entry in the CHANGELOG.md file to describe the changes made by this PR |
| :warning: | This PR is larger than 500 lines of changes. Please consider splitting it into smaller PRs for easier and faster reviews. |
| 1 Message | |
|---|---|
| :book: | This PR is still a Draft: some checks will be skipped. |
Generated by :no_entry_sign: Danger
👋 @AliSoftware, long overdue but could we maybe close, or remove @Automattic/apps-infrastructure from this draft to make it stop showing in my list of PRs to review on GitHub and when Slack gives me a daily brief, will much appreciated reducing some noise. 🙏
I've removed the team as reviewer, but honestly I think we could as well merge those docs even if they are not perfect, and iterate later if we find errors or refinements to make on those at some point, but at least we'd have a starting point?
I've removed the team as reviewer, but honestly I think we could as well merge those docs even if they are not perfect, and iterate later if we find errors or refinements to make on those at some point, but at least we'd have a starting point?
Sure, I agree, it is just that the PR is draft I guess, thus no-one is reviewing it (I think)... 🤷
Sure, I agree, it is just that the PR is draft I guess, thus no-one is reviewing it (I think)... 🤷
I guess nobody is reading PR descriptions, those days 😇
Even if I'm keeping it as Draft until it's properly reviewed, I've still added the team as reviewer of this PR already, so that we can start have some humans taking a deeper look at the changes it generated.
But fair enough, I think that was probably one of the reasons indeed. I'll maybe try to find some time to make a quick human pass at it then switch to ready for review at some point.