The first of the @gitea 1.17 stable release was published a few hours ago. 🚀

Get ready to upgrade and make sure to check the "HOWTO Gitea upgrades, a guide for admins" published at before you do. ☘️

gitea.hostea.org/Hostea/admin-

---

Authored by @dachary

is looking for a co-founder with a business mindset 🌱 Someone who likes and , feeling adventurous and ready to bring to what @markosaric brought to @plausible

Very much looking forward to meeting you ❤️

forum.hostea.org/t/looking-for

---

Authored by @dachary

tip: @Gitea 1.17.0-rc2 is out and requires moving (again) a custom .gitconfig.

That's mostly relevant for production Gitea installations based on the Docker "latest" tag that unexpectedly got upgraded to the release candidate.

The Hostea blog post explains in details what happened and how to deal with the change.

hostea.org/blog/1-17-breaking-

---

Authored by @dachary

tip: if you are running Gitea from docker 1.16 and wonder why you did not get the latest 1.16.9 yesterday, try again today.

The 1.16 tag was not updated and stayed on 1.16.8.

It has been manually updated today to match 1.16.9 (for amd64 only, not arm).

---

Authored by @dachary

is committed to provide hosting for @gitea instances with ActivityPub federation features enabled as soon as Gitea 1.18 is published.

It will also provide hosting for experimental @forgefriends and developer releases for everyone to try.

forgefriends.org/blog/2022/06/

---

Authored by @dachary

tip: obtaining the newly generated GPG key signing the Gitea 1.16.9 release may fail because the key server is unresponsive. The following oneliner will be useful to retry (in my case six times):

while : ; do if gpg --keyserver keys.openpgp.org --recv 7C9E68152594688862D62AF62D9AE806EC1592E2 2> /dev/null ; then echo success break ; else echo -n . ; fi ; done
......success

docs.gitea.io/en-us/install-fr

---

Authored by @dachary

tip: If you install the newly released Gitea 1.16.9 and get the following error message when verifying the signature of the binary:

gpg: Note: This key has expired!

It does not necessarily mean that it was compromised. The cryptographic key used to sign releases expired a few weeks ago and was not renewed yet.

If you run a highly sensitive Gitea instance (I know of at least two), you may want to wait until a new signature is issued.

docs.gitea.io/en-us/install-fr

---

Authored by @dachary

The "HOWTO Gitea upgrades, a guide for admins" moved to a repository: contributions are welcome 🚀

It previously was on a forum wiki page. But after a few months and 60+ edits, it became clear that regular updates will be necessary to keep up.

It was used to help with a few dozens upgrades and became the source of truths for Hostea system administration.

gitea.hostea.org/Hostea/admin-

---

Authored by @dachary

tip: the installation instructions in the @gitea documentation reference the 1.16.9 release that has not yet been published. It is an oversight that can be fixed by replacing 1.16.9 with 1.16.8.

$ wget -O gitea dl.gitea.io/gitea/1.16.8/gitea

docs.gitea.io/en-us/install-fr

---

Authored by @dachary

tip: the GPG key used to sign releases expired about two weeks ago:

$ gpg --list-key 7C9E68152594688862D62AF62D9AE806EC1592E2
pub rsa4096 2018-06-24 [SC] [expired : 2022-06-24]
<teabot@gitea.io>

It can however still be used to verify the integrity of the 1.16.8 release published a week before.

docs.gitea.io/en-us/install-fr

---

Authored by @dachary

The first version of the "HOWTO upgrades, a guide for admins" is available 🚀 Make sure to read it before performing your next @gitea upgrade, what you will learn in a few minutes may save you hours of painful work ✨

forum.hostea.org/t/howto-gitea

---

Authored by @dachary

tip: If a @gitea instance stopped working today with this error:

Your database (migration version: 218) is for a newer Gitea, you can not use the newer database for this old Gitea release (211).

It needs to be upgraded to 1.17.0-rc1 to resume operations.

During a few minutes around 00h15 UTC the Gitea 1.16.9 release was accidentally set to latest and caused the downgrade.

Read on for more details at forum.hostea.org/t/gitea-downg

---

Authored by @dachary

tip: if your @gitea instance was unexpectedly upgraded from 1.16.8 to 1.17.0-rc1 ⚠️ do not ⚠️ try to revert back to 1.16.8.

Less than 24h ago the "latest" tag on the docker hub was moved from 1.16.8 to 1.17.0-rc1 by mistake. It should be set to the latest stable version, which 1.17.0-rc1 is not.

Downgrading to 1.16.8 is not supported and will cause problems.

See the "HOWTO Gitea upgrades, a guide for admins" for more information.

forum.hostea.org/t/howto-gitea

---

Authored by @dachary

tip: when Gitea is installed from from binary, you need to run it with --work-path in addition to -c to make the doctor work:

gitea doctor --work-path /var/lib/gitea -c /etc/gitea/app.ini

It is not enough to provide @Gitea with the configuration file, it always needs the --work-path argument, or the GITEA_WORK_DIR environment variable.

Reason why it is set in the systemd service file:

github.com/go-gitea/gitea/blob

---

Authored by @dachary

tip: running `gitea doctor` on a docker `gitea/gitea:1.16.8` installation can be done with:

docker exec --user git --workdir=/tmp gitea gitea doctor --all

The --user git is because it otherwise runs as root and is not setup properly to run gitea. And the --workdir is because it otherwise does not have permission to write the log file in the container.

When using `gitea/gitea:1.16.8-rootless` there is no need for these extra flags.

---

Authored by @dachary

tip: only use `gitea doctor --all` and never `gitea doctor --run`.

Because of a bug in @gitea v1.16.8 the `--run` option may silently discard the messages reporting errors or warning.

Until it is fixed, the simplest workaround is to use the `--all` option instead: it is more noisy but accurate.

---

Authored by @dachary

tip: make sure to upgrade docker to version 20.10.6 or later before upgrading to @gitea 1.17 (which will be released in a few weeks).

Otherwise you will experience mysterious breakage. This can be done at any time: it is compatible with the latest Gitea 1.16. If in doubt, take a look at the HOWTO Gitea upgrades guide for admins for the latest tips.

forum.hostea.org/t/howto-gitea

---

Authored by @dachary

tip: when @Gitea is installed with docker, here is how you will want to run the doctor 🩺 to verify it is not sick 🤕

docker exec --user git gitea gitea doctor --all --log-file /tmp/doctor.log

Should there be a need for more information looking 👀 in the doctor.log will display the gory details:

docker exec --user git gitea cat /tmp/doctor.log

---

Authored by @dachary

A instance brought to the clinic was successfully upgraded from 1.11.0 to 1.16.8 🚀

A test run was conducted to identify potential issues and there was no surprise when upgrading the production instance.

It was also an opportunity to fix a minor bug in the Gitea doctor command and to improve the Hostea upgrade guide.

gitea.hostea.org/dachary/hoste

---

Authored by @dachary

tip: the gitea doctor command is available starting with 1.10.5 & 1.10.6 and for all versions >= 1.11.5.

But contrary to what one would expect it is not available for Gitea 1.11.0, 1.11.1, 1.11.2, 1.11.3, 1.11.4.

This was discovered today while migrating a Gitea 1.11.0 instance and the HOWTO Gitea upgrade was updated with this tip.

forum.hostea.org/t/howto-gitea

---

Authored by @dachary

Show older

Hostea Gitea Hosting & Clinic's choices:

Mastodon

A newer server operated by the Mastodon gGmbH non-profit