Windows Gogs To Gitea Upgrade Notes

[atom0s]

• Gitea version (or commit ref): a74426d
• Git version: 2.17.1.windows.2
• Operating system: Windows Server 2012 R2 Standard
• Database (use [x]):
  • PostgreSQL
  • MySQL
  • MSSQL
  • SQLite
• Can you reproduce the bug at https://try.gitea.io:
  • Yes (provide example URL)
  • No
  • Not relevant

Description

There are a lot of problems with the upgrade from Gogs to Gitea that are not really covered at all in the docs. This leads to a lot of Google searches, browsing previous issues on here, and so on to piece together some important information when moving to Gitea. This is my experience over the last 24 hours of moving my Gogs install to Gitea and some extra steps I had to deal with along the way. I am making this in hopes to help someone else as well as to share some information I feel should be added to the Upgrade docs, especially for Windows installs.

MySQL Requirements

Gitea does not give a specific MySQL server version requirement in their docs. Gogs recently changed their requirements to 5.7 fairly quietly, so previous installs would land up with errors randomly. Gitea absolutely requires at least MySQL 5.7.x as I learned the hard way on a 5.6.x install personally.

Gitea will fail every upgrade due to MySQL issues with 5.6.x and previous. Gogs' newer versions will also have silent issues if you are not upgraded to at least 5.7.x.

For those on Windows, you can do an in-place upgrade based on the information here:
https://dev.mysql.com/doc/refman/8.0/en/windows-upgrading.html

I recommend reading the full page first before doing anything as the steps are unclear and some feel out of order which can lead to data loss if you are not careful. Backup everything first as well, both the server install and your data just in case. An in-place upgrade to the latest 5.7 zip package worked fine for me. If your SQL server fails to start, check the event log on Windows as the upgrade for me did not report errors the log file for some reason. I had to manually create an 'Uploads' folder in the data folder when I upgraded to get my server to start again, for example.

Gitea Upgrade Process

Gitea is very fragile when upgrading. I attempted to do a quick upgrade from Gogs to Gitea 1.0.x then upgrade to the latest master of Gitea and it failed horribly. Some digging around yielded a mention in a random ticket here that you should do a major revision step-up upgrade, meaning that after you are running on Gitea 1.0.x, upgrade to each major revision one by one such as:

• 1.0.x
• 1.2.3
• 1.3.3
• 1.4.3
• (Any new major revisions after the time of this report.)
• Current Master

Doing this allowed my install to upgrade properly. Another important note, I highly recommend that you rename the Gitea exe that you are using to just 'gitea.exe' each time. There are steps in the Gitea upgrade process and initialization that are not greatly handled yet and cause errors otherwise.

For example, Gitea 1.2.x and higher create certain hook files, which use the exe's name in the file. Gitea does not update this path and file name after the fact when upgrading to a newer version. So for me, when I ran the 1.2.x exe with its default name, the hooks were made with the file name 'gitea-1.2.3-windows-4.0-amd64.exe' in them. Afterward, attempting to commit to a repo will error saying the file was not found after an upgrade to a newer Gitea version and exe. Renaming the file to gitea.exe and doing the upgrades after will fix this issue. If you happen to upgrade before hand, you can use something like Notepad++ to rename the exe in all hook files fairly easily.

Another issue that Gitea has is it will cause issues with previous Gogs hooks. Gogs creates certain receive hooks that Gitea is not compatible with and will throw errors when they are executed. These hooks are located in:
- /pre-receive.d/pre-receive
- /post-receive.d/post-receive

These contain gogs' exe name and will error due to it. These files should be deleted manually. For Windows users, I personally had to write a program to do it since Windows lacks a powerful 'find' command that Linux users can use to do this. (And I'm not savvy in powershell enough to use it to do this.)

For Linux users, see this issue comment:
#3558 (comment)

There is a tool in the Gitea admin panel that can rewrite these hooks to make this easier than deleting them manually.

Gitea As A Service

Gitea can be registered as a Windows service using the built-in Windows 'sc' command. However, those upgrading from Gogs on Windows may have been using the recommended 'nssm' tool. This does not work with Gitea, at least for me. No matter what I did I could not get Gitea to work with it.

Because of this, it's important to remove the old nssm service that was registered for Gogs and then manually create the new one via the 'sc' command. (Gitea does have docs for how to do this.)

Gitea Breaks Discord Webhooks

After upgrading to Gitea, I found that Gitea breaks all my Discord web hooks. In gogs, the web hook task type id was 3. In Gitea, it's 4. To fix this, I did a simple SQL query:

UPDATE `database-name-here`.webhook SET hook_task_type = 4 WHERE hook_task_type = 3;

Before running this, I recommend you manually check the table as upgrade versions may vary on what the ids are for you. Doing this fixed my Discord web hooks.

---

At this time, I just recently (in the last few hours) upgraded to Gitea. So other issues are bound to arise. I will try and keep this updated with any other problems and fixes I come across that I have to do to my personal Gitea install.

[techknowlogick]

Another issue that Gitea has is it will cause issues with previous Gogs hooks. Gogs creates certain receive hooks that Gitea is not compatible with and will throw errors when they are executed. These hooks are located in:

There is an option in the admin dashboard to rewrite all of these hooks

[atom0s]

Thanks for that heads up! Didn't notice that before I wrote a prog to delete them.

Another issue I found, Gogs 0.v11+ changed how the web hook secret is sent which Gitea does not implement this way currently. Users that relied on this change with their services taking in the data will have to revert to the older format of looking for the secret in the blob sent as the data instead.

Info here on that change in gogs:
gogs/gogs@6ec859f

[deoren]

Some digging around yielded a mention in a random ticket here that you should do a major revision step-up upgrade, meaning that after you are running on Gitea 1.0.x, upgrade to each major revision one by one such as:

1.0.x
1.2.3
1.3.3
1.4.3
(Any new major revisions after the time of this report.)
Current Master

How important is this order? I went off of the current doc today which recommends moving from Gogs to the latest Gitea 1.0.x version (1.0.2 as of today), then after all related steps were completed (e.g., replacing "gogs" with "gitea" everywhere) I was free to use the latest stable version by just replacing the main executable.

I've only invested about a week into the old setup (using Gitea as a mirror for now); am I better off starting from scratch with the latest stable or is it safe to move from Gogs to Gitea 1.0.x, then 1.4.3?

[atom0s]

For me, it was very important. Failure to step through each major revision caused a ton of database errors when Gitea started up and tried to do its automatic upgrade steps. I tried to go from 1.0.x to the current master at the time and it failed horribly cause of database problems. I reverted and restored Gogs and tried again going from 1.0.x to 1.3.x and it still had similar problems. So I stepped through each revision and it worked fine.

Results may vary based on server setups and such, but I would highly recommend stepping through each major revision like I mentioned for the best results. It doesn't take long to do either, Gitea is pretty fast to upgrade between each version.

[deoren]

@atom0s Thank you for the feedback. I've definitely noticed some odd behavior since I upgraded (most recently double activity entries when force-pushing squashed feature branches), so I may end up going the direction you proposed.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.

[stale]

This issue has been automatically closed because of inactivity. You can re-open it if needed.