Re-add the PRs that are reverted from main
due to introducing breaking changes to github.com on the v35.26.0 release
#3429
Labels
main
due to introducing breaking changes to github.com on the v35.26.0 release
#3429
Due to the recent deploy freeze at dotcom, we were unable to release primer/react on a regular schedule and this impacted the scope of the release candidate, therefore made it very challenging for us to address failing tests at dotcom. As a team, we made a decision to revert the PRs that we are introducing breaking changes to be able to get the current release out. Here is the PR that reverts the PRs that introducing breaking changes.
This issue focuses on adding them back to
main
to be released in one of the upcoming releases.If you are assigned to this issue, it is high likely that we had to revert your PR(s) (apologise again ❤️ ) but now it is time to add back in.
Create a (draft) PR in primer/react
Create a new (draft) PR in https://github.com/primer/react with your reverted changes. You can cherry-pick the reverted commit on top of
main
or if you have a different idea/way of doing it, feel free to do it. If you decide to go with cherry-pick, you can find the commit ID to cherry-pick in your original PR, towards the bottom. Example: "Merged via the queue into main with commit 9532977 on May 16" Sorry if you already know about this stuff, I just wanted to make sure we don't block anyone in case they are not familiar with reverting/re-adding commits.For example, I created one for my reverted octicon changes #3428
Canary version of
@primer/react
at PR timeWe release a canary version of primer react, everytime when there is a new PR created as well as the PR receives new commits. If you scroll to the CI checks of your newly created draft PR, you will see one job that publishes these canary packages. ie.e "Published @primer/react — 0.0.0-xyz" - You can use this 0.0.0-xyz version to test your changes at github.com
Dotcom development environment setup
Open up your dotcom development environment. If this is your first time, please refer to the hub documentation. If you have any problems setting up your dotcom environment, please ask help on these slack channel.
Installing the canary version at dotcom
Now we can install the canary version
0.0.0.xyz
at dotcom (hub reference)Above comment will do most the work but we need some manual work to clean up. Please see this discussion (very short one, don't worry!) if you are curious about why node_modules might get messed up. Feel free to follow the instructions on the discussion or if you are already aware of this problem and have your own way of resolving, feel free to do it. I am just going to list clean up steps that I have found working nicely.
The main idea of this clean up is that we don't want any node_modules under npm-workspaces/primer
Testing changes at dotcom
Hopefully things go smoothly on the previous step and you can now test your changes. We usually push a draft PR to dotcom and rely on CI checks to see if the changes has any issues with integrating in dotcom. Feel free to run tests/checks on your CodeSpace if this is your prefered way of testing the changes.
After identifying the failings/issues with your PR, there are possibly 2 ways to go forward:
If you feel comfortable implementing backwards compatible fixes/enhancements, great! If not, no worries. Please tag us
@primer/react-reviewers
on your PR and we can look into the PR and can suggest backwards compatible alternatives.If the PR cannot be introduced with a backwards compatible implementation, we should fix the breakings/failings at dotcom.
We are aiming to see all green checks on our integration PRs at dotcom so that we can merge our primer/react PRs confidently.
I hope this is helpful, sorry it is a bit long! Please let me know if you have any concerns/questions/feedback or recommendation of the workflow!
The text was updated successfully, but these errors were encountered: