Project Defaults

Project defaults let administrators configure shared settings for all projects in one place. Root projects inherit these defaults, and child projects inherit settings through their parent projects. This is useful for maintaining common settings across multiple project hierarchies.

note

Project defaults require an active enterprise subscription.

Configure Project Defaults

1. Log in to OneDev as an administrator.
2. Open Administration / Project Defaults.
3. Select the setting category, make your changes, and save.

The available settings include:

• Default roles and user/group authorizations
• Branch and tag protection, code indexing, and Git pack configuration
• Pull request settings and the issue branch prefix
• Job secrets, job properties, build preserve rules, and default fixed issue filters
• Workspace specs and cache preservation
• Wiki settings, web hooks, and AI settings

Under General, you can configure default roles. Project identity and options such as the project name, description, and enabled features are configured separately in each project.

How Inheritance Works

For settings with a single inheritable value, such as the issue branch prefix, OneDev uses the value defined in the project first. If no value is set, it checks the parent project, continuing up to the root project and then project defaults. If project defaults also leave the value unset, OneDev uses its built-in fallback.

The placeholder indicates what happens when an inheritable field is left unset:

Where you edit the setting	Placeholder behavior
Administration / Project Defaults	Shows the built-in fallback, such as No prefix or All files
Root project with an active subscription	Shows Use default setting
Child project	Shows Inherit from parent

To override a single-value default, set a value under the project's Settings. Clear that value to resume inheritance. Changes to project defaults affect existing and new projects that inherit the setting; they are not just initial values copied when a project is created.

Settings containing permissions or lists follow their own inheritance rules. For example, default role permissions accumulate, branch and tag protection rules are inherited along with local rules, and job properties and workspace specs can be overridden by name. A local entry does not necessarily replace the entire inherited collection. Refer to the help on each settings page for details.

Without an active subscription, root projects use their built-in fallback for unset values instead of project defaults. Child projects can still inherit from their parents.

Example: Require a CI Job

Suppose each project defines a CI job named ci that compiles its code and runs its tests. You can make successful builds of this job a shared requirement for changes to main:

1. Open Administration / Project Defaults / Code / Branch Protection and add a rule.
2. Set Branches to main and Applicable Users to anyone.
3. Under Required Builds, enter ci and press ENTER. You can type the job name even if it is not listed.
4. Disable Prevent Creation if projects should be able to create their main branch, then save the rule.

Root projects inherit this rule, and child projects inherit it through their parents. Wherever the rule applies, updates to main require a successful ci build for the changes. Each project defines and runs its own ci job; project defaults share the build requirement, not the job definition.

Branch protection uses the first enabled rule matching the branch and applicable user, checking local rules before inherited rules. A project-specific matching rule can therefore take precedence over the shared rule. To retain the shared build requirement in such a rule, include ci under its Required Builds as well.