make main as default branch

[Patel-Raj11]

High Level Overview of Change

Make main as default branch to avoid staging to main PR during release. This also helps removing all the users who have push to main access and all the commits go through pull request reviews before they are merged and released.

Context of Change

Type of Change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Refactor (non-breaking change that only restructures code)
• Tests (You added tests for code that already exists, or your new feature included in this PR)
• Documentation Updates
• Translation Updates
• Release

Codebase Modernization

• Updated files to React Hooks
• Updated files to TypeScript

Before / After

Test Plan

1. Existing tests should pass.
2. CI should run and pass.
3. Force push on main should not be allowed. - Works - remote: - Changes must be made through a pull request. error: failed to push some refs to 'github.com:ripple/explorer.git'
4. Requires 2 approvals before merge into main.

[mvadari]

Are deploys still automatic on pushes to main?

[Patel-Raj11]

Are deploys still automatic on pushes to main?

Deploys were not automatic on pushes to main. So we still trigger them here

[mvadari]

Are deploys still automatic on pushes to main?

Deploys were not automatic on pushes to main. So we still trigger them here

That was the primary reason we had the separate branches, previously.

[Patel-Raj11]

That was the primary reason we had the separate branches, previously.

I see. We could still change the release flow to trigger automatic release once the PR is merged into main or to trigger when it sees a new tag (if we want to accumulate all the changes and release it in a batch).

The reason to make main as the default branch is to avoid keeping two branches. Currently, when a squashed commit is created into main branch, it gets out of sync from staging branch and subsequent merge into main fails (unless we do main to staging merge).

Also, currently, the flow requires someone to locally merge commits from stating into main (without squashing) and then push to main. This could lead unnecessary changes that are not reviewed in PRs. So, it's better to have only one branch where everyone's code gets reviewed and merged.

[kuan121]

@mvadari @Patel-Raj11
I'm not aware of what automated deployment we have or had for Explorer, but I'm thinking of having a CI/CD release pipeline that will look like this

1. Merge a PR into main
2. Pipeline triggers automatic deployment to dev environment
3. Pipeline is blocked
4. Someone clicks an approval button to manually trigger a deployment to the staging env
5. Pipeline is blocked
6. Developers perform whatever manual verifications they want/should
7. Someone clicks an approval button to manually trigger a deployment to the prod env

This way, we wouldn’t need to open PRs just to merge branches around, or manually trigger a GitHub workflow per environment (readme). We could even drop steps 3 and 4 and have every merge auto-deploy to dev and staging with no human intervention. If we want a more complete setup with rollback support, we could deploy from tags instead of deploying directly from a branch.

This PR moves us one step closer to that goal.

[mvadari]

@mvadari @Patel-Raj11 I'm not aware of what automated deployment we have or had for Explorer, but I'm thinking of having a CI/CD release pipeline that will look like this

1. Merge a PR into main
2. Pipeline triggers automatic deployment to dev environment
3. Pipeline is blocked
4. Someone clicks an approval button to manually trigger a deployment to the staging env
5. Pipeline is blocked
6. Developers perform whatever manual verifications they want/should
7. Someone clicks an approval button to manually trigger a deployment to the prod env

This way, we wouldn’t need to open PRs just to merge branches around, or manually trigger a GitHub workflow per environment (readme). We could even drop steps 3 and 4 and have every merge auto-deploy to dev and staging with no human intervention. If we want a more complete setup with rollback support, we could deploy from tags instead of deploying directly from a branch.

This PR moves us one step closer to that goal.

Yes, that makes sense. Just wanted to make sure there wasn't an auto deploy to prod on every commit to main 🙂