Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

🐛 [Forgejo] Stuck in old versioning scheme #6390

Open
3 tasks done
Lockszmith-GH opened this issue Jan 15, 2025 · 3 comments
Open
3 tasks done

🐛 [Forgejo] Stuck in old versioning scheme #6390

Lockszmith-GH opened this issue Jan 15, 2025 · 3 comments
Labels
bug Something isn't working

Comments

@Lockszmith-GH
Copy link

Store Application

Forgejo

App version

1.21.11-0

Description

According to the Forgejo releases page The latest version is v9.0.3 and the LTS version is v7.0.12
both updated December 2024

Runtipi is on 1.21.11-0 which is the old versioning scheme.

The project documentation explains that after v1.21 the scheme was changed to comply with semantic versioning.

Steps to reproduce

Latest version of Forgejo is 1.21.11-0

App logs

N/A

Browser

No response

Browser logs

No response

User-Config changes

No response

Other

No response

Please confirm the following

  • I believe this issue is a bug that affects all users of RunTipi, not something specific to my installation.
  • I have already searched for relevant existing issues and discussions before opening this report.
  • I have updated the title field above with a concise description.
@Lockszmith-GH Lockszmith-GH added the bug Something isn't working label Jan 15, 2025
@Lancelot-Enguerrand
Copy link
Collaborator

Lancelot-Enguerrand commented Jan 15, 2025

Hello @Lockszmith-GH,

According to release scheme, from where we are (1.21), there is 3 new major versions :

  • 7.0 (LTS)
  • 8.0
  • 9.0 (stable)

The bigger step is to go from v1.21 to v7,
If we are able to do it, I will suggest to go directly to v9.
I would prefer to have someone who actually uses the app to test the migration (which I am not).

Here below the breaking changes from release notes.

Release 7.0.0

Link : https://codeberg.org/forgejo/forgejo/src/branch/forgejo/RELEASE-NOTES.md#7-0-0

Regressions and workarounds:

  • Running the forgejo doctor check --fix CLI command or setting [cron.gc_lfs].ENABLED=true (the default is false) will corrupt the LFS storage. The workaround is to not run the doctor CLI command and disable the cron.gc_lfs. This regression will be fixed in 7.0.1.
  • The forgejo admin user create CLI command requires a password change by default when creating the first user and the --admin flag is not specified. The --must-change-password=false argument must be given to not require a password change. This regression will be fixed in 7.0.1.

Breaking changes requiring manual intervention:

  • Forgejo webhooks now always send full refs (starting with refs/) instead of sending short refs in some cases. This new behavior may require changes when the receiving end assumes a short ref will be received (for instance some versions of Woodpecker CI when receiving webhook payloads when a tag is set).
  • MySQL 8.0 or PostgreSQL 12 are the minimum supported versions. The database must be migrated before upgrading. The requirements regarding SQLite did not change.
  • The per_page parameter is no longer a synonym for limit in the /repos/{owner}/{repo}/releases API endpoint.
  • The date format of the created and last_update fields of the /repos/{owner}/{repo}/push_mirrors and /repos/{owner}/{repo}/push_mirrors API endpoint changed to be timestamps instead of numbers.
  • Labels used by pprof endpoint have been changed:
    • graceful-lifecycle to gracefulLifecycle
    • process-type to processType
    • process-description to processDescription This allows for those endpoints to be scraped by services requiring prometheus style labels such as grafana-agent.
  • The repository description imposes additional restrictions on what it contains to prevent abuse. You may use the v7.0 test instance to check how it will be modified.
  • The Gitea themes were renamed and the [ui].THEMES setting must be changed as follows:
    • gitea is replaced by gitea-light
    • arc-green is replaced by gitea-dark
    • auto is replaced by gitea-auto

Breaking changes in the user interface: Note that the modifications related to CSS, templates or assets (images, fonts, etc.) are not documented here. Although they can be extracted and modified, Forgejo does not provide any guarantee that such changes will be portable from one version to another (even a patch version). See also the developer documentation about interface customization.

Update checker setting might change. The documentation was listing it as enabled by default, however, for a while it was disabled unless it was explicitly specified in the config or on the installation page. Instances migrated from Gitea also had it disabled due to different default value. Since then Forgejo got a privacy-friendly DNS-based update checking mechanism which is now being enabled by default unless explicitly specified in the config.
Language statistics for repositories that use linguist attributes in .gitattributes may show different statistics than previously, because Forgejo recognizes more linguist attributes now.
It is no longer possible to replace the default web editor used to write comments or issues and pull requests with the EasyMDE editor. It is however still available as an alternative to edit releases and wiki pages.
The list of all repositories and the New Issue button are no longer available in the user dashboard for issues and pull requests.

Migration warning

If the logs show a line like the following, run doctor convert to fix it.
[W] Current database is using a case-insensitive collation "utf8mb4_general_ci"

Large instances may experience slow migrations when the database is upgraded to support SHA-256 git repositories. For instance, here are the logs from a test migration of the https://codeberg.org production database:

[I] Migration[286]: Add support for SHA256 git repositories
[W] [Slow SQL Query] ALTER TABLE `commit_status` MODIFY COLUMN `context_hash` VARCHAR(64) [] - 3m41.647738396s
[W] [Slow SQL Query] ALTER TABLE `comment` MODIFY COLUMN `commit_sha` VARCHAR(64) [] - 1m5.500234133s
[W] [Slow SQL Query] ALTER TABLE `release` MODIFY COLUMN `sha1` VARCHAR(64) [] - 22.06241145s

Release 8.0.0

Link : https://codeberg.org/forgejo/forgejo/src/branch/forgejo/RELEASE-NOTES.md#8-0-0

  • Remove Microsoft SQL Server support see the discussion.

Release 9.0.0

Link: https://codeberg.org/forgejo/forgejo/src/branch/forgejo/release-notes-published/9.0.0.md

  • OIDC integrations that POST to /login/oauth/introspect without sending HTTP basic authentication will now fail with a 401 HTTP Unauthorized error. To fix the error, the client must begin sending HTTP basic authentication with a valid client ID and secret. This endpoint was previously authenticated via the introspection token itself, which is less secure.
  • Existing tokens with a public scope will no longer return private resources. They have to be deleted and re-created without the public scope to restore their original behavior. The public scope of an application token does not filter out private repositories, organizations or packages in some cases. This scope is not the default, it has to be manually set via the web UI or the API. When the public scope is explicitly added to an application token that is allowed to list the repositories and packages of a user or an organization, it is meant as a restriction. For instance if a user has two repositories, one private and the other publicly visible, a token with the public scope used with the API endpoint listing the repositories that belong to this user must only return the publicly visible one and not reveal the existence of the private one.
  • Drop support to build Forgejo with the optional go-git Git backend. It only affects users who built Forgejo manually using TAGS=gogits, which no longer has any effect. Moving forward, we only support the default backend using the git binary. Please get in touch if you used the go-git backend and require any assistance moving away from it.

@Lockszmith-GH
Copy link
Author

Lockszmith-GH commented Jan 15, 2025

Yes, I've read the release notes.

And just like any other upgrade, major releases bring with them possible breaking changes.

Today I will go through the upgrade process one step at a time (by editing image yaml tag in user-config stepping into v7 then v8, and finally v9)

My setup is standard, so I'm not expecting any trouble.

I'll report back

@Lockszmith-GH
Copy link
Author

Sorry for not responding sooner. OBE, should get to this this week.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants