Config as code - switching default the branch causes the project to break

We are testing out Config as Code, and we had to change the default branch. However, that seems to break the project, and the only way to fix it is to re-create the old default branch. For the record, we use GitHub for our repos.

Here’s what we did:

  1. Create a repo with default branch “main” (this was a mistake as we generally use “master” as our default branch).
  2. Set up the Octopus project pointing to “master”. The branch was created.
  3. When we noticed the error in step #1 we changed the default branch in the repo to “master”. That renames the branch, so “main” is now gone.
  4. Now when we access any of the project pages (Process, Releases, etc.) we get an error: “There was an error accessing version control.”

If I create a new branch called “main” then everything works again. If I again delete main (which remember is NOT the default branch in the repo, but a regular branch), the problem returns.

If I click “Test” in version control settings, after verifying the correct default branch is set (master), it returns with success.

If I try to set the default branch to “main”, in order to switch it back to master in hope of “resetting” something, we get: “Remote repository returned an error: cannot delete branch ‘refs/heads/main’ as it is the current HEAD of the repository.” (note that main does not exist in our repo at this time).

If I create the “main” branch in GitHub, and then try to switch the project to default branch “main”, I get the following error: “Corrupt repository. The ‘HEAD’ reference is missing.”

This is just a test project so we can recreate it - but it would be good to have a workaround if this occurs again in the future, as well as knowing if there’s a fix in the works. Also, is there any way to clone the repo again for instance? Or some other way to reset it?

Good morning @hallgeir.osterbo,

Thank you for contacting Octopus Support and sorry to hear you are running into issues when renaming your default main branch on your version controlled project.

I am wondering if you are running into this GitHub issue, are you able to take a look at it and see if it is what you are experiencing?

If so are you able to clear the Git Cache as suggested in the GitHub issue and see if you can then rename the branch?

I look forward to hearing from you,

Kind Regards,

Clare

1 Like

Hi @clare.martin - thanks for the quick feedback on this.

We will test this out and let you know how it works. Thanks!

Is this something that will be fixed down the line, so that the workaround will not be needed in the future when switching default branches? (Not that we will do that THAT often).

Hey @hallgeir.osterbo,

When a GitHub issue is raised it is so our engineers can look into it and provide a fix for our customers so we will definitely be following it through and trying to put a fix in place for this, if a fix cannot be provided we usually end up finding some other way of doing it for our customers.

If you subscribe to that issue I linked you will receive updates and also you will be notified when a fix is out and what patch version that fix has been implemented in so you can upgrade if you want to.

I hope that news is welcomed, let me know if clearing the Git Cache doesn’t work though and we can look into this further.

I will add your forum ticket onto the GitHub issue just so out engineers have an idea of how many users this is currently affecting.

I look forward to hearing from you,

Kind Regards,

Clare

1 Like

This did not seem to work - in fact now it’s perhaps even more broken :smiley:

Each page still gives the same error (“There was an error accessing version control”).
If I now try to change the default branch, I get this error:

Remote repository returned an error: Path 'E:\Octopus\Git\3M7IDOWPSGPND7EKNPH4OAIH57C7JCXF\root' doesn't point at a valid Git repository or workdir.

Hey @hallgeir.osterbo,

Hmmm, what an interesting development! I am going to try and test this from my end and see if it does the same thing for me.

In the meantime it might be worth re-creating the test project just so you have it working again whilst I set everything up my end and test this out.

What version of Octopus are you running at the moment? I notice you have a cloud instance but that E:\ in the path on your error seems more like a Server thing than cloud.

I look forward to hearing from you,

Kind Regards,

Clare

We use on-premises Octopus Deploy, not the cloud hosted instance. The version is 2022.1 build 2744.

Hey @hallgeir.osterbo,

I have not managed to work on this yet but I was looking at something else earlier and I came across a user that had the same issue as you, he cleared the Git Cache but after looking in his logs the cache didn’t actually clear properly (he had an access denied error for clearing the Git Cache which is a separate issue we have logged here)

What he had to do was manually remove all files from his local cache (in your case this would be here - ‘E:\Octopus\Git\3M7IDOWPSGPND7EKNPH4OAIH57C7JCXF\root’) - Note - he did have to restart the Octopus Service to clear it fully as some ‘files were in use’) so you may have to do that to get that folder to clear properly.

Are you able to try this out and see if that fixes the issue, if not I will carry on with my investigations surrounding this.

Kind Regards,

Clare

Hi again @clare.martin. Thanks for the tips. I didn’t get a chance to test your suggestion here, but I did try something else that seems to have solved the issue. The workaround was to change the version control settings to a different repo, then change it back again. That seems to have cleared up all the issues we saw.

Time will tell if there’s anything more laying around though.

Hey @hallgeir.osterbo,

Excellent news thank you for sharing that workaround, I will pop it on the GitHub issue as something other customers can use until we can find an official fix for this.

Let me know if it breaks again though and we can look into it further, thank you for our patience whilst we worked through this together,

Kind Regards,

Clare

1 Like

Thanks @clare.martin! :slight_smile:

1 Like

This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.