Prepare to rename default branch to "main"

[hamishfagg]

This makes changes to prepare for the following changes to align with our SDLC:

• Rename the staging branch to main
• Delete the stable branch

Development would then progress like this:

• Code is developed in a dev's own branch
• Code is tested and optionally deployed to a dev env in this branch
• Code is merged to main and is automatically deployed to https://staging.mindsdb.com
• When a github release is created, main will be deployed to prod.

[ea-rus]

Questions:

• Why branch is renamed from 'staging' if it is deployed to staging.mindsdb.com? Isn't the old branch name better suited?
  Code is merged to main and is automatically deployed to https://staging.mindsdb.com/
• If PR is developed by community member - will it possible to deploy to a dev for him?
• Where in this flow is the stage to run e2e tests? After it we should almost completely sure in new changes

[StpMax]

I am wondering about environment conflicts. At the moment, there are 70 open PRs. What if some of them are actively developing and have the 'deploy_to_dev' tag? In that case, what will be deployed? How can i be sure, and how can i check that my branch is in the dev environment?
If few branches merged in staging in short time - are we sure that all changes will be deployed? or may be 'deploy' job of last PR may finish earlier, then previous?
Do we really want to run deploy to staging on each merge? Most of merges is doc changes, or just small fixes.

[hamishfagg]

@ea-rus

• Why branch is renamed from 'staging' if it is deployed to staging.mindsdb.com? Isn't the old branch name better suited?
  Code is merged to main and is automatically deployed to https://staging.mindsdb.com/

The naming between the branch and the environment were coincidental. e.g. we don't have a branch named for any other environment (hackathon, demo, dev, prod etc). It's an industry standard for the default branch to be called main.

• If PR is developed by community member - will it possible to deploy to a dev for him?

Yes this won't change. Right now contributors outside of MindsDB can't run Github actions for security reasons, it requires approval from a MindsDB member. So they can deploy to dev with approval, and they will still be able to after this change.

• Where in this flow is the stage to run e2e tests? After it we should almost completely sure in new changes

There are several stages we should be running different kinds of tests and those are laid out in the SDLC linked above.

To be clear, this renaming doesn't really change any of our processes. staging is our default branch now, and main will contain the same code and still be our default branch. It's literally just changing what it's called. stable will disappear, and be replaced by tags/releases in main (but currently every commit to stable is tagged, so it's basically a redundant branch).

[hamishfagg]

@StpMax

I am wondering about environment conflicts. At the moment, there are 70 open PRs. What if some of them are actively developing and have the 'deploy_to_dev' tag? In that case, what will be deployed?

When you rename a branch in Github, it also updates all of the PRs to be pointing to the new name. So this isn't an issue, and we've tested this on several of our other repos. What gets deployed to dev envs is whatever is in the developer's own branch, so that won't change.

How can i be sure, and how can i check that my branch is in the dev environment?

This is more of a process question for us. Currently when a deploy is done, a message is sent to the #alerts-github-pulls channel in slack and shows you who triggered the deploy, and which branch/commit is being deployed.

If few branches merged in staging in short time - are we sure that all changes will be deployed? or may be 'deploy' job of last PR may finish earlier, then previous? Do we really want to run deploy to staging on each merge? Most of merges is doc changes, or just small fixes.

This is a good question and I remember looking into this when setting up the deploy to staging script, but I need to confirm that the behavior is sane if this happens. That said, this rename doesn't change any of this behavior - we currently deploy to staging for every merge into the staging branch. So that's something we're already doing. We could also add some ignore paths so we don't deploy if we haven't changed any code.

[mindsdb-devops]

lgtm