-
Notifications
You must be signed in to change notification settings - Fork 2.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Refactor and clean up the createStagingDeployIssue code #9999
Comments
Low priority for now |
Focusing on API refactors and n7 |
Still in my backlog, I will let this once to the pool if anyone is interested |
Overall I think we may have lost the context for this issue and the problem is unclear. I think we should refine the problem statement or close this out. |
@roryabraham I think the general goal was to mrefactor the entire code to me more accessible to unfamiliar developers. A bit vague goal I know. However, coming back to what you mentioned before offshore, about reworking the deploy process, is there anything you planned for the deploy checklist and how we create it? then we might just close this out and focus on this later |
Triggered auto assignment to @puneetlath ( |
I didn't really have anything major planned for the checklist other than removing some outdated naming (i.e: replace |
Alright, I think from the bugZero perspective, we can close this one out. The issue got created when we were trying to add a new feature to the checklist and it revealed how easy it is to miss something in the complicated code. However, we havent had issues with the checklist for a long time or needs to change it so I think we could close this now and if there would be any new bigger changes required for the checklist in future, the refactoring should take place along with it. Let me know if you disagree. |
Sounds good to me. |
Problem
Coming from #9946 (comment)
The code for creating staging deploy issue is very hard to follow and leads to bugs when new features are added or code is changed as engineers have tough time following the code.
Also sometimes we can manually move PRs to be internalQA after being added to the checklist - try to check if the PRs in main section are indeed internal or not before adding them in - do not rely on previous checklist in terms of this.
Why is this important?
Intoruduced more bugs in the issues which slows down deploy and takes more time to fix.
Solution
We should do:
App/.github/libs/GithubUtils.js
Line 192 in d24ab21
And:
Lets also update naming to make sure it is not outdated:
cc @roryabraham
The text was updated successfully, but these errors were encountered: