Gitea Workflows and Module Help Needed

We migrated to the new platform. The general information is in this blog post. Here is additional information for developers (this list can be updated as more is found).

Labels and Project Boards

A few important things to understand for module owners and the triaging team:

  • Bug triaging will assign labels to reports. Type, status, priority and module must be set for a report to be considered fully triaged. The triaging team should not assign issues to project boards. See the bug triaging docs for details.
  • It is up to every module how they want to organize their board, or even use multiple boards. We recommend to put only to do and design issues on the project board, and perhaps a few bug reports if they are part of a specific planning.
  • Each project board will have links to a query for classified and unclassified bug reports.
  • Assign every non-WIP pull request to a relevant project board, so it gets seen by the relevant developers.

Help Needed from Modules

  • One empty project board has been created per module. Design and to do issues need to be added to the board, which can be done with batch editing in the issue list. The old workboards are available on the archived for reference.
  • Note that an issue can only be placed on a single project board, while it may currently be part of multiple workboards on You will need to decide what goes where in such cases.
  • Old project tags have been migrated as labels with a legacy prefix. If you prefer to continue using a legacy label, check that they are assigned to the right issues and then rename the label. To name a label to indicate relevance to a project or module, use the interest/ prefix. After a while the remaining legacy labels will be removed. Wait a bit with removing any labels until the triaging team has checked it’s safe to remove them.
  • Each module gets a wiki page on the blender repository. This replaces the old project description page. Please update your page to fix broken links and make it well formatted.
  • If you used parent and child tasks, those relations will have to be manually recreated.

Commits, Issues & Pull Requests references

By default, commits can be referenced by their git hash (9fecf1f8b8), and similarly for issues and pull requests using their uid (#93407).

However, this will only work properly for references to items within a same organization/repository.

Commits from another repository can be referenced by pre-fixing the organization/repository ‘path’, and using an @ instead of the #: blender/blender@9fecf1f8b8

Issues and pull requests from another repository can be referenced by pre-fixing the organization/repository ‘path’: blender/blender#93407

Wiki Templates

Templates to reference commits, issues etc. on have been updated.

  • {{GitCommit|}} has been updated, with a new, future-proof recommended syntax: {{GitCommit|1234567890|flamenco|studio}}
  • {{Issue|}} replaces the old {{BugReport|}}.
  • {{PullRequest|}} replaces the old {{PhabDiff|}}.

These three new templates follow the same parameter logic: uid|repository|organization_or_fork, the last two being optional and defaulting to blender/blender.


There is an automated bot to start builds, keep closed and open issues status valid, and add information to commits about the issues, pull requests and other commits referencing them. More information here:


The subversion repositories cannot be browsed from, but remain active with plans to migrate them to git-lfs.

For committing to svn repositories, you must generate an application token to use as your password.

Differences with Phabricator

  • Subscription to issues are controlled by the users themselves and not visible to others. @ mentions will not subscribe others, they will get an email and notification, and can then choose to subscribe. @ mentions autocomplete only includes participants in the issue and members of a team in the blender organization.
  • Changing issue labels, projects and milestones does not send notifications or emails. So also leave a comment if others need to be notified.
  • If you want to get emails for your own actions, there is an option for that in the email account settings.
  • Gitea does not currently remember unsubmitted comments when closing issues or pull requests. Be sure to save them somewhere if you want to continue later.
  • Merging duplicate issues is not natively supported currently. You have to manually close the issue, and write a comment like this: “Merged into #123. Please subscribe there if you want to see further updates”.
  • You can place pull requests on a project board.
  • The command line tool for Gitea is tea. This is more of an optional thing than arc, pull requests work fine without it.
  • If you made commits with another email address than your Blender ID, you can add additional email addresses in the account settings to have them recognized as yours.

See Render & Cycles for an example of links on the landing page and project board:

I’ve noticed one issue when adding multiple reviewers. The first seems to work fine, but it’s hard to get the second to do anything. When I manage to add another reviewer, it’s not clear what I did differently.

I’ve tried selecting the reviewer and refreshing the page, or selecting the reviewer and just waiting. Neither seem to work. Anyone else seeing this?

This bug is fixed now.


This is pretty nitpicky, but I thought I might bring it up in case the team is looking to improve stuff like this.

When looking through the pull requests, I find the branches take up a lot of visual weight, but they’re really not so important. I’d expect to see that information when looking at the PR, but in a list of all PRs it’s just noise.

I wonder if we’re able to tweak things enough to remove that, if others agree anyway.

Edit: Also, wanted to say that working with Gitea is very pleasant already. Well done to everyone on the transition :slight_smile:


I have a quick tip for users whom (like me) got used to having bookmarked to quickly report bugs, as well as browse bugs reported by others or check on the bugs they’ve reported:

Replace your bookmark with this link:

  1. You can check notifications about the updates on the issues you’ve reported just like you did with the phabricator.
  2. There’s a quick acces to Report a Bug button, just like in phabricator.
  3. You have a simple vertical list of the recently reported issues, just like with phabricator.
  4. You can view list of the issues you’ve reported, just like in phabricator.

Only thing I really miss was to be able to see recent commits and recent issues on the same screen. The commit feed on was nice as I was often discovered exciting new updates just at a glance while checking on bug reports.


When you get to it, it seems like “git blame” support is broken on the site.

My local files have the correct blame data but that’s with a repo that was used before. I’m not sure what it would look like with a freshly cloned repo directly from gitea but I hope the disparity is limited to just the web.

Some examples:

1 Like

Must be a gitea visualization issue, I’ve logged it here:

1 Like

Posting here my suggestions for changes in the dark color theme to make diffs more readable by toning down some backgrounds to be less distracting:

:root {
--color-box-body-highlight: hsla(204deg, 60%, 15%, .15);
--color-diff-inactive: hsl(229.4, 13.8%, 13%);
--color-diff-added-row-linesnum-bg: hsla(123, 36%, 40%, 0.2);
--color-diff-removed-row-linesnum-bg: hsl(0, 25%, 23%);

The idea is:

  • The blue lines separating patch hunks should be way less prominent than file headers: visual priority should be red/green changes → file headers → everything else. In default phab color scheme they are very subtle, and I matched that.
  • I think it is strange that in side by side view (e.g. this commit at random) ‘holes’ on the other side of additions/removals are brightly colored - I made them slightly darker than default background instead.
  • Finally, in the same vein as the other changes, I made the color of the number column of red/green changes slightly closer to the non-number column.

Edit: it’s quite likely an actual designer could tune the colors even better - this is just a suggestion of the direction of change.


Thanks @angavrilov, these changes have been incorporated now.

1 Like

@brecht, Hi, where can I find diffusion/B/history/master page now?

You mean blender/blender - blender - Blender Projects ?

1 Like

I find this helps remove clutter from the PR list. (don’t know if it affects something else though)

.issue.list .branches {
 display:none !important;
 padding:0 4px




Yes, thanks. For some reason that whole ‘panel’ didn’t work for me, so I thought it was purely decorative element with some information slapped on it.

Good idea! I’ve applied the changes now in production.

Nice, so much easier for the eyes. I think I got the idea to remove them from @HooglyBoogly .

A few recent changes:

  • Convention is now to assign every non-WIP pull request to a project, so that it appears on project boards.
  • Fixed blame views
  • Fixed problem with pull request updates showing way too many commits
  • Added compare button for force pushed commits

Does main page doesn’t exist anymore? Where you would see new topics and commits from all modules? Right now it seems I can only see them for separate modules

it is all here in the activity tab