Document process on synchronizing GH issue labels
Follow up from https://github.com/causify-ai/helpers/pull/426#discussion_r2014557205,
Things to consider:
- When one creates/updates/deletes a label now, they should also go to this file and update it
- once the file is updated, who should do it and to which repos (since not everyone can see and has the permission to all the repos)?
Options:
- Use GH Action pipeline
Maybe we can also have a GH pipeline that detect changes in this file when label file is merged to master and then execute the changes? This way, we are still relying on our script to perform the change and use GH Action as a way to detect the changes and execute our script, or even perform regular maintenance through cronjob.
- Run the script manually
I see the advantage of the user then only needing to update the yaml file when they update the labels. However, with running the script yourself there is more control, one can see logging messages, etc. So I would lean towards keeping the script in the hands of a human.
FYI @sonniki @gpsaggese
I'm adding it to the same project as its parent issue https://github.com/causify-ai/csfy/issues/5514, although they don't fit well inside that project. Since we'll be having more things to work on such as merge properties, GH projects template, ...etc. Should we put them into their own GH project? @gpsaggese @sonniki
This particular issue could potentially go in the documentation project but a new GH project is also fine by me.
We can create a GH project dev_system-v...: Automate GH, since there are several things we are trying to do.
All related issued moved to DevSystem-v2.6 - Automate GH
IMO as we are iterating on several options to do this (such as GH Actions, python script, bash script, dockerized executable, and invoke target), the way to go is probably:
- Create a python script that does the syncing (either using the
ghCLI tool or the python lib) - Wrap it in a dockerized executable
- (Optional depending on the decision in https://github.com/causify-ai/helpers/issues/439#issuecomment-2803402815) Expose it as an invoke target (so the person with the right permission to the repo can just run
i syn_gh_issue_labelfor example on the repo without needing to specify the org name or repo name)
WDYT? @gpsaggese @sonniki @Shaunak01
The plan sounds good.
As we said the invoke is just to "package" / keep organized workflows.
Done