Branch on snc repo should follow openshift repo branching

[praveenkumar]

Right now we are try to keep our master in sync with whatever is released version of openshift (in current case it is 4.14). Idea is to have same branching as openshift repo so that we can avoid some of issues.

• Right now we push code to master (which is ideally for 4.14) and then cherry-pick it for 4.15 branch which is kind of backward instead we push to the master and then cherry-pick to respective branch and if a branch doesn't need it then just put PR on that branch and no need to cherry-pick.

• Openshift installer have e2e-crc tests which is failing for quite some time because snc master is capable to create bundle only for 4.14 and installer goes to 4.16-4.17 and it fails.

• We can create branch early on like 4.16 to do layer testing for engineering candidate also.

• Also we don't need to create https://github.com/crc-org/snc/pull/811 or https://github.com/crc-org/snc/pull/725 to have master update for next released version.

We update our README to have this info so the consumer of snc knows how to create the bundle for specific openshift/microshift release.

[cfergeau]

No strong opinion on the branch naming, as long as one key requirement is met: everyone knows for sure which branch is going to be used next time we release a bundle, and it is the branch which is tested the most, any issues with this branch becomes high priority, crc is tested against this branch, ...

Why not testing 4.16 early, but we also have to be clear that any issue found there is not going to be high priority (eg PRs may take some time to be reviewed).

[praveenkumar]

everyone knows for sure which branch is going to be used next time we release a bundle, and it is the branch which is tested the most, any issues with this branch becomes high priority, crc is tested against this branch, ...

Agree, and our internal job able to take branch name as argument for creating the bundle. we can always set the default branch to something than master/main on github like release-4.14 so that when someone create PR it should by default taken to that branch and then PR owner select different branch as it fits.

Why not testing 4.16 early, but we also have to be clear that any issue found there is not going to be high priority (eg PRs may take some time to be reviewed).

Sure, PR review for master or non release version take some time because that would be not high priority but we can get issue very early on once e2e-crc on installer side fixed.

[cfergeau]

we can always set the default branch to something than master/main on github like release-4.14 so that when someone create PR it should by default taken to that branch

This means something we need to remember to manually update every few months, otherwise we won't be testing the right thing.

[praveenkumar]

we can always set the default branch to something than master/main on github like release-4.14 so that when someone create PR it should by default taken to that branch

This means something we need to remember to manually update every few months, otherwise we won't be testing the right thing.

Currently following way we do the test

• Run the CI job against PR (so after changing the default branch, PR would be created against that branch so if author wants to have it for different branch then it can be set accordingly during PR creation. There is no change around CI job run.
• Create release bundle from internal CI and that is also have option to use the branch info for which we want to use to create the bundle so that is also provided manually. (No change there also)

So even if we forget to update this default branch, I don't think on PR side and internal CI there is issues or do I miss something here?

Note: I just changed the default branch to release-4.14 and every change is now goes through master => respective branch. At least want to see if that offer better maintenance without compromising our testing quality.