Add PublicReleaseDownloads repository setting to allow direct release downloads without authentication for Limited visibility repos. Adds migration v369, checkbox in Advanced Settings (only shown for Limited repos with releases enabled), and updates attachment serving logic to check HasPublicReleases. Moves release download routes outside auth requirement when public downloads enabled. Complements existing pages config PublicReleases toggle.
Add OwnerDisplayName field to Repository model to allow custom display name for repository owner (e.g., "John Smith" instead of username). Used in license generation, social cards, and other public-facing contexts. Includes migration v368 to add column, UI in repository settings, and updates to license creation and social card rendering to use display name when available.
Add repository setting to control anonymous access to app integration endpoints (issue submission, update checks). When enabled (default), the desktop app can access these endpoints without authentication. When disabled, vault token authentication is required.
This provides granular control over app integration access, allowing repository owners to enforce full authentication on sensitive repositories while maintaining ease of use for public/limited repos.
Changes include:
- New PublicAppIntegration boolean field on Repository model
- Database migration v365 to add the field (defaults to true)
- Repository settings UI to toggle the feature
- Updated checkVaultTokenForRepo to respect the setting
- Security enhancement: IssueStatusJSONEndpoint now only returns app-submitted issues to anonymous users
Adds comprehensive blog post system for repositories with draft/public/published status, featured images, tags, and subscriptions. Includes database models, migrations, CRUD operations, email notifications, explore page, and full UI templates for creating, editing, and viewing blog posts.
Adds new social card customization options including solid color backgrounds and custom background images with Unsplash integration. Introduces new database fields for storing color, background image URL, and Unsplash attribution. Adds media kit settings page for repository-level social card configuration.
Implement Open Graph social card image generation with customizable themes. Cards are dynamically rendered with repository name, description, owner avatar, and GitCaddy branding.
Features:
- Three built-in themes: dark (default), light, and colorful
- 1200x630px cards optimized for social media platforms
- Avatar fetching with caching and fallback to default
- Text wrapping and truncation for long descriptions
- Repository settings UI for theme selection
- Migration to add social_card_theme column
Technical implementation:
- Uses golang.org/x/image for rendering with Inter font family
- Singleton renderer pattern for font reuse
- Endpoint: /:owner/:repo/socialcard.png
- Integrates with Open Graph meta tags in head template
Add Inter font files (Regular and Bold) and GitCaddy logo asset.
Add repository setting to hide files and folders starting with "." from non-admin users in the code browser. Admins can still see dotfiles displayed dimmed. Includes database migration, settings form, filtering logic for tree views and file listings, and locale strings.
Introduces a new "limited" visibility level between public and private. Limited repos are publicly browseable but restrict clone, fork, and archive downloads to collaborators only. Adds database migration, UI controls in settings, enforcement in git HTTP and SSH handlers, and corresponding locale strings.
Adds a GroupHeader field to repositories allowing them to be grouped under custom headers on organization pages. Includes database migration v333, form handling, and grouped/ungrouped view toggle in the UI.
Go's semantic import versioning requires v2+ modules to include the
major version in the module path. This enables using proper version
tags (v3.x.x) instead of pseudo-versions.
Updated module path: code.gitcaddy.com/server/v3
- Add repository display title field shown in header and explore listings
- Add license settings page with predefined license types
- Auto-create LICENSE.md when license type is selected
- Show license in repo sidebar with link to LICENSE.md
- Add API header link option in theme settings
- Default explore/organizations sort to alphabetical
- Show org DisplayName only in /explore/organizations
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Per-repository signing keys have never been officially supported, as
they would require users to modify the repository’s config file.
At this point, it is clear that only global signing keys (GPG or SSH)
should be allowed. If we want to introduce per-repository signing keys
in the future, it will require a complete design proposal.
The endpoint will not be removed for repository special signing key, but
it will reference the global signing key.
---------
Signed-off-by: Lunny Xiao <xiaolunwen@gmail.com>
Co-authored-by: delvh <dev.lh@web.de>
Partially fix#32018
`git config` and `git remote` write operations create a temporary file
named `config.lock`. Since these operations are not atomic, they must
not be run in parallel. If two requests attempt to modify the same
repository concurrently—such as during a compare operation—one may fail
due to the presence of an existing `config.lock` file.
In cases where `config.lock` is left behind due to an unexpected program
exit, a global lock mechanism could allow us to safely remove the stale
lock file when a related error is detected. While this behavior is not
yet implemented in this PR, it is planned for a future enhancement.
---------
Signed-off-by: wxiaoguang <wxiaoguang@gmail.com>
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
* Signed SSH commits can look in the UI like on GitHub, just like gpg keys today in Gitea
* SSH format can be added in gitea config
* SSH Signing worked before with DEFAULT_TRUST_MODEL=committer
`TRUSTED_SSH_KEYS` can be a list of additional ssh public key contents
to trust for every user of this instance
Closes#34329
Related #31392
---------
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
Co-authored-by: techknowlogick <techknowlogick@gitea.com>
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
This PR tries to finally fix the bug mentioned in #30011 and #15504,
where the user repo limit is checked when creating a repo in an
organization.
Fix#30011
---------
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
Co-authored-by: TheFox0x7 <thefox0x7@gmail.com>
Follow #33127Fix#8649, fix#639
This is a complete solution. A repo unit could be set to:
* Anonymous read (non-signed-in user)
* Everyone read (signed-in user)
* Everyone write (wiki-only)
Follow #33127
This PR add backend logic and test for "anonymous access", it shares the
same logic as "everyone access", so not too much change.
By the way, split `SettingsPost` into small functions to make it easier
to make frontend-related changes in the future.
Next PR will add frontend support for "anonymous access"
- Both have `RejectTransfer` and `CancelTransfer` because the permission
checks are not the same. `CancelTransfer` can be done by the doer or
those who have admin permission to access this repository.
`RejectTransfer` can be done by the receiver user if it's an individual
or those who can create repositories if it's an organization.
- Some tests are wrong, this PR corrects them.
---------
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
`RepoTransfer` now is at models, but if we want to move it into `repo`
model, it will depend on `Team`. So this PR also makes repo model depend
on org model to make it possible. Just refactor, no code change.
- [x] Move `DeleteOrganization` from `models/organization` to service
layer
- [x] Move `AccessibleTeamReposEnv` to `models/repo`
- [x] Move `RepoTransfer` from `models` to `models/repo`
- [x] Merge `getUserTeamIDs` and `GetUserTeamIDs`, Merge `GetUserTeams`
and `getUserTeams`.
- [x] Remove `Team`'s `Repos []*repo_model.Repository` to avoid dependency recycle.
Since `modules/context` has to depend on `models` and many other
packages, it should be moved from `modules/context` to
`services/context` according to design principles. There is no logic
code change on this PR, only move packages.
- Move `code.gitea.io/gitea/modules/context` to
`code.gitea.io/gitea/services/context`
- Move `code.gitea.io/gitea/modules/contexttest` to
`code.gitea.io/gitea/services/contexttest` because of depending on
context
- Move `code.gitea.io/gitea/modules/upload` to
`code.gitea.io/gitea/services/context/upload` because of depending on
context
With this option, it is possible to require a linear commit history with
the following benefits over the next best option `Rebase+fast-forward`:
The original commits continue existing, with the original signatures
continuing to stay valid instead of being rewritten, there is no merge
commit, and reverting commits becomes easier.
Closes#24906
Fix#28157
This PR fix the possible bugs about actions schedule.
## The Changes
- Move `UpdateRepositoryUnit` and `SetRepoDefaultBranch` from models to
service layer
- Remove schedules plan from database and cancel waiting & running
schedules tasks in this repository when actions unit has been disabled
or global disabled.
- Remove schedules plan from database and cancel waiting & running
schedules tasks in this repository when default branch changed.
Introduce the new generic deletion methods
- `func DeleteByID[T any](ctx context.Context, id int64) (int64, error)`
- `func DeleteByIDs[T any](ctx context.Context, ids ...int64) error`
- `func Delete[T any](ctx context.Context, opts FindOptions) (int64,
error)`
So, we no longer need any specific deletion method and can just use
the generic ones instead.
Replacement of #28450Closes#28450
---------
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
