blog/content/post/release-of-1.19.0.md at 6ec0f0a9716a875c49beb569caf684f7d8f25d69

39 KiB

Raw Blame History

date

authors

title

Thank you!

The Blender team for their extensive work on this version, i.e. through issues, pull requests, and support of the Gitea Project.
@wxiaoguang, @fsologureng, and everyone else who has been helping with the accessibility changes.
@yardenshoham for his contribution on Gitea Backporter, which makes our backport work significantly easier than before.
@pat-s for his work to make static website PRs previewable.

We would also like to thank all of our supporters on Open Collective who are helping to sustain us financially.

You can download one of our pre-built binaries from our downloads page - make sure to select the correct platform! For further details on how to install, follow our installation guide.

We are now working on moving our infrastructure from gitea.io to gitea.com, as well as migrating from Drone CI to Gitea Actions. During this conversion, if you encounter any problems, please report them via discord.

Have you heard? We now have a swag shop! 👕 🍵

Breaking Changes

⚠️ Incorrectly documented default value for update checker (#22084)

[cron.update_checker].ENABLED is true by default. Previously, the documentation indicated that it would be disabled by default, which was incorrect.

⚠️ Newly reserved username: `gitea-actions` (#21937)

With the implementation of Gitea Actions (see below), Gitea needed a user to run the actions. The username gitea-actions was chosen and is thus now reserved. If a user with that name exists, an admin should rename them, i.e. using the admin panel.

⚠️ Remove DSA host key from Docker Container (#21522)

The DSA host key has been removed from the OpenSSH daemon configuration file in the Docker container for Gitea. This change is a result of the deprecation of the DSA public key algorithm since OpenSSH >= 7.0. As a result, any client that uses DSA for authentication will no longer be able to connect to the Docker container. We recommend users to use a different public key algorithm such as RSA or ECDSA for authentication.

⚠️ Remove ReverseProxy authentication from the API (#22219)

ReverseProxy-authentication was an insecure way of authenticating a user. Hence, it was dropped without replacement. Any user that relied on it must switch to basic or token authentication now.

⚠️ Remove `[ui].ONLY_SHOW_RELEVANT_REPOS` setting. (#21962)

On the explore page, you can switch whether you only want to see relevant repos, or all repos. As this page already offers a link to switch between these two options, this setting only had a negligible effect and complicated the logic by a lot. Hence, it was dropped without replacement. You can now remove it from your app.ini if present.

⚠️ Restrict valid user names (#20136)

Valid user names now follow the following rules:

allowed letters are -,., _, 0-9, a-z, A-Z
names must not start or end with -,., or _
names must not have consecutive -,., or _. (i.e. a-.b is illegal)

No action must be taken for existing users. This is only enforced for newly created users.

⚠️ Separate allowed units for normal repos and forks (#22541)

Previously, fork repositories had all default units. Now, forks only enable code access and pull requests by default. If you want everything to behave like before, please set the setting [repository].DEFAULT_FORK_REPO_UNITS to the value of [repository].DEFAULT_REPO_UNITS.

⚠️ Support camel case for issue and code search when using Bleve (#22829)

In order to be able to support queries that include camel case tokens, the indexes must be rebuilt. This is an automatic process that will be done on the first startup without any user interaction.

⚠️ Support commit description in the merge template (#22248)

Previously, your whole default_merge_message template file was considered to be the commit title. Now, only the first line is the commit title, and the rest (from line 3 on) is the commit description, just like in normal commits.

Highlights

🚀 Gitea Actions (#21937)

One of the biggest requests of all time has finally made it into Gitea (for now as a preview): Gitea Actions. Gitea Actions is a built-in CI system like GitHub Actions. With Gitea Actions, you can reuse your familiar workflows and Github Actions in your self-hosted Gitea instance. While it is not currently fully compatible with GitHub Actions, we intend to become as compatible as possible in future versions. The typical procedure is as follows:

Register a runner (at the moment, act runners are the only option). This can be done on the following scopes:
- site-wide (by site admins)
- organization-wide (by organization owners)
- repository-wide (by repository owners)
Create workflow files under .gitea/workflows/<workflow name>.yaml or .github/workflows/<workflow name>.yaml. The syntax is the same as the GitHub workflow syntax where supported. (The link points at the GitHub documentation as we don't have our own docs yet) For example, try the following test file which Gitea uses to pre-build the available act_runner binaries:

name: goreleaser

on:
  push:
    branches: [ main ]

jobs:
  goreleaser:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
        with:
          fetch-depth: 0
      - run: git fetch --force --tags
      - uses: actions/setup-go@v3
        with:
          go-version: '>=1.20.1'
      - name: goreleaser
        uses: https://github.com/goreleaser/goreleaser-action@v4
        with:
            distribution: goreleaser-pro
            version: latest
            args: release --nightly
        env:
          GORELEASER_KEY: ${{ secrets.GORELEASER_KEY }}

Commit and push the workflow files
If everything has been set up correctly, the workflows will be run whenever one of its triggers has been triggered:

Huge thanks to the authors of actions (@wolfogre, @lunny, @appleboy and @fuxiaohei), of @nektos, all contributors of act for act_runner, and @delvh for significant effort spent reviewing the PRs.

More information can be found in the issue to implement actions, and you can find a small tutorial in our blog.

🚀 Asciicast support (#22448)

It is now possible to view uploaded Asciicast (.cast) files. Asciicast is an efficient format to convert a textsequence time interval (i.e. a terminal session) into a video. A picture (or in this case three) is worth a thousand words: First, you open the file as any other file: Then, you start watching the video: One of the key features of asciicast videos is that the text contained in it can be selected.

Thanks to @wolfogre

🚀 Cargo (#21888), Chef (#22554), Conda (#22262) package registries and package limits/cleanup (#21584, #21658)

Gitea 1.19 ships with three new package registries that coincidentally all start with C:

Cargo (Rust)
Chef (language agnostic)
Conda (especially Python, can also be used for other languages)

Furthermore, it is now possible to limit how large an uploaded package can be, or when packages will be deleted again to save space.

Thanks to @KN4CK3R for all of his work adding each of the new package registry types and restricting the amount of space consumed by packages.

🚀 Citing repos (#19999)

Repositories with a CITATION.cff file will now automatically display a hint to cite the repository. To find the dialogue, click on … to open the menu for additional actions.

Thanks to @Nolann71

🚀 Copy file content (#21629)

It is now easier than ever before to copy the content of a whole file:

Thanks to @yardenshoham

🚀 Pre-built FreeBSD binaries (#22397)

Now we provide official pre-built FreeBSD binaries.

Thanks to @techknowlogick for the many year effort of adding FreeBSD support to XGO, and to the FreeBSD community for their advice throughout the process

🚀 Highlight `Note` and `Warning` in markdown quotes (#21711)

The first **Note** or **Warning** found in a markdown quote (> text) will automatically be highlighted now:

Thanks to @yardenshoham

🚀 LFS GC (#22385)

Unreferenced LFS files will now be cleaned as well after a while.
Previously, such files would simply accumulate forever.

Thanks to @zeripath

🚀 Projects for organizations/users (#22235)

If you have ever had at least two repositories that were related to each other, you probably hated working with projects. This has now improved tremendously as Gitea 1.19 allows you to define projects on a "global" level, to track work in multiple repositories.

Thanks to @lunny

🚀 Referencing commits across repos (#22645)

We were surprised too when we noticed that Gitea doesn't support referencing a commit in another repository yet. Said and done, you can now reference commit 123456789 in repo owner/repo by using the syntax owner/repo@123456789, when you are talking about that specific commit even if you're not inside of repo owner/repo at the moment.

Thanks to @KN4CK3R

🚀 Reply by email (#22056)

It is now possible to reply to a mail about a comment to create a new comment.

Thanks to @KN4CK3R and @a1012112796 for their work on this widely requested feature

🚀 Restrict access token permissions (#20908)

Previously, all access tokens had all permissions.
Now, you can set which permissions access tokens may have to prevent unintended access.
FYI: We call these restrictions scoped access tokens.

Thanks to @harryzcy for increasing the security of Gitea

🚀 Scoped labels (#22585)

Whenever a label contains a / in its name (not at either end), you can decide if a label should be exclusive. For example, if the labels kind/bug and kind/enhancement have the exclusive option set, an issue may only be classified as a bug, or an enhancement, but not both. You can see in the screenshot, that multiple Kind labels can be set, but only one Priority label. Additionally, scoped labels are highlighted differently. By the way, the labels you can see in the screenshot are part of the new label set Advanced that is shipped by default with Gitea 1.19. It mimics the labels Gitea uses for its own development. Read more about (scoped) labels in the documentation.

Thanks to @brechtvl and the rest of the Blender team for adding this functionality to Gitea

🚀 Secrets (#22142)

Repos, users and organizations can now store secrets that can be used for example inside Gitea actions. These secrets cannot be seen by anyone who isn't an owner of the repo or organization.

Thanks to @wolfogre, @lunny and @lafriks

🚀 Wildcard branch protection (#20825)

Previously, branch protection was limited to a single branch that had to exist. Now, you can use wildcards such as

* (to protect all branches)
feature/*-test (to protect all branches that start with feature/, end with -test, and have no / inbetween)
test/** (to protect all branches starting with test/, no matter what comes afterward).