- Add a visual (but still semantic way) separation between Forgejo's
generated attachments and the user's uploaded ones.
- The styling was first done by `ul` element, but is moved to the
individual list items to have better control over them.
- Add tooltip explaining the attachment was generated by Forgejo.
- Remove the tooltip of the other attachments and 'simplify' them into a text.
- Resolves#2893
Co-authored-by: 0ko <0ko@noreply.codeberg.org>
On creation of an empty project (no template) a default board will be
created instead of falling back to the uneditable pseudo-board.
Every project now has to have exactly one default boards. As a
consequence, you cannot unset a board as default, instead you have to
set another board as default. Existing projects will be modified using a
cron job, additionally this check will run every midnight by default.
Deleting the default board is not allowed, you have to set another board
as default to do it.
Fixes#29873Fixes#14679 along the way
Fixes#29853
Co-authored-by: delvh <dev.lh@web.de>
(cherry picked from commit e5160185ed65fd1c2bcb2fc7dc7e0b5514ddb299)
Conflicts:
options/locale/locale_en-US.ini
trivial conflict because Forgejo strings do not have
surrounding double quotes
- Replace links from docs.gitea.com with forgejo.org/docs for those
where the relevant links are available on the Forgejo documentation.
- Resolves#2892
- Currently protected branch rules do not apply to admins, however in
some cases (like in the case of Forgejo project) you might also want to
apply these rules to admins to avoid accidental merges.
- Add new option to configure this on a per-rule basis.
- Adds integration tests.
- Resolves#65
1. Use general "mobile-only" and "not-mobile" CSS styles, remove some`@media (max-width: 767.98px)` tricks
2. Use `CountFmt` for repo list, just like the repo header (and it matches GitHub, to avoid big numbers bloat the page)
(cherry picked from commit bfa160fc98a23923b6ce1cd4d99e8970d937d6ec)
Conflicts:
templates/explore/repo_list.tmpl
templates/repo/header.tmpl
web_src/css/repo/header.css
Resolved the template conflicts by porting the changes to Forgejo (in
case of `header.tmpl`, applying the changes in `header_fork.tmpl). In
case of the CSS change, opted to take Gitea's version and drop the
entire media query.
Fix#28761Fix#27884Fix#28093
## Changes
### Rerun all jobs
When rerun all jobs, status of the jobs with `needs` will be set to
`blocked` instead of `waiting`. Therefore, these jobs will not run until
the required jobs are completed.
### Rerun a single job
When a single job is rerun, its dependents should also be rerun, just
like GitHub does
(https://github.com/go-gitea/gitea/issues/28761#issuecomment-2008620820).
In this case, only the specified job will be set to `waiting`, its
dependents will be set to `blocked` to wait the job.
### Show warning if every job has `needs`
If every job in a workflow has `needs`, all jobs will be blocked and no
job can be run. So I add a warning message.
<img
src="https://github.com/go-gitea/gitea/assets/15528715/88f43511-2360-465d-be96-ee92b57ff67b"
width="480px" />
(cherry picked from commit 2f060c5834d81f0317c795fc281f9a07e03e5962)
The error message:
`editor.file_changed_while_editing = The file contents have changed
since you started editing. <a target="_blank" rel="noopener noreferrer"
href="%s">Click here</a> to see them or <strong>Commit Changes
again</strong> to overwrite them.`
Is re-used in inappropriate contexts. The link in the key goes to a 404
when the key is used in a situation where the file contents have not
changed.
Added two new keys to differentiate commit id mismatch and push out of
date conditions.
(cherry picked from commit 16e360099d0a515d429538ec88cff1f3ede23fb4)
- If a branch cannot be renamed due to a protected branch rule, show
this error in the UI instead of throwing an internal server error.
- Add integration test (also simplify the existing one).
- Resolves#2751
Repositories displaying an "Add more..." tab on the header is a neat way
to let people discover they can enable more units. However, displaying
it all the time for repository owners, even when they deliberately do
not want to enable more units gets noisy very fast.
As such, this patch introduces a new setting which lets people disable
this hint under the appearance settings.
Fixes#2378.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
- Currently in the Cargo section of the packages setting menu two
buttons are always shown, "Initalize index" and "Rebuild index", however
only of these should be shown depending on the state of the index, if
there's no index the "Initalize index" button should be shown and if
there's an index the "Rebuild index" button should be shown. This patch
does exactly that.
- Resolves#2628
Detect broken git hooks by checking if the commit id of branches in DB
is the same with the git repo.
It can help #29338#28277 and maybe more issues.
Users could complain about actions, webhooks, and activities not
working, but they were not aware that it is caused by broken git hooks
unless they could see a warning.
<img width="1348" alt="image"
src="https://github.com/go-gitea/gitea/assets/9418365/2b92a46d-7f1d-4115-bef4-9f970bd695da">
It should be merged after #29493. Otherwise, users could see a ephemeral
warning after committing and opening the repo home page immediately.
And it also waits for #29495, since the doc link (the anchor part) will
be updated.
---------
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
Co-authored-by: Giteabot <teabot@gitea.io>
(cherry picked from commit a4bcfb8ef1d5b2b522f78c9560d53ddbdbb02218)
(cherry picked from commit a6eb298098983b7aae028fff4d80d15d5510f10b)
Conflicts:
options/locale/locale_zh-CN.ini
branding Gitea/Forgejo conflict
new transations in [graphs]
- When a user goes opens a symlink file in Forgejo, the file would be
rendered with the path of the symlink as content.
- Add a button that is shown when the user opens a *valid* symlink file,
which means that the symlink must have an valid path to an existent
file and after 999 follows isn't a symlink anymore.
- Return the relative path from the `FollowLink` functions, because Git
really doesn't want to tell where an file is located based on the blob ID.
- Adds integration tests.
Continuation of #2444, which introduced the commit
bf7fb89178 but only added
the label and the tests.
The tooltip explaining what AGit is and its advantages is not
meant to advertise AGit - it is meant to inform the reader that
is presumably not familiar with the workflow that they will not
be able to find a fork or a branch associated with the Pull Request
as a direct consequence of this workflow.
Issue #2474 mentions that we should show instructions on how to
fetch an AGit-created Pull Request, and this is the plan. However,
this may take time, so I might as well make the label a bit more
"complete" and less out-of-place for now if we do not manage to
improve these instructions until the next release (Forgejo v1.22).
Refs: https://codeberg.org/forgejo/forgejo/issues/2474
This is the implementation of Recent Commits page. This feature was
mentioned on #18262.
It adds another tab to Activity page called Recent Commits. Recent
Commits tab shows number of commits since last year for the repository.
(cherry picked from commit d3982bcd814bac93e3cbce1c7eb749b17e413fbd)
### Overview
This is the implementation of Code Frequency page. This feature was
mentioned on these issues: #18262, #7392.
It adds another tab to Activity page called Code Frequency. Code
Frequency tab shows additions and deletions over time since the
repository existed.
Before:
<img width="1296" alt="image"
src="https://github.com/go-gitea/gitea/assets/32161460/2603504f-aee7-4929-a8c4-fb3412a7a0f6">
After:
<img width="1296" alt="image"
src="https://github.com/go-gitea/gitea/assets/32161460/58c03721-729f-4536-a663-9f337f240963">
---
#### Features
- See additions deletions over time since repository existed
- Click on "Additions" or "Deletions" legend to show only one type of
contribution
- Use the same cache from Contributors page so that the loading of data
will be fast once it is cached by visiting either one of the pages
---------
Co-authored-by: Giteabot <teabot@gitea.io>
(cherry picked from commit 875f5ea6d83c8371f309df99654ca3556623004c)
Fixes#27188.
Introduces a check on the installation that tries to parse the FROM
address. If it fails, shows a new error message to the user.
---------
Co-authored-by: KN4CK3R <admin@oldschoolhack.me>
(cherry picked from commit 6f6120dfa8d549d0b866eeb9317054fea831c844)
Conflicts:
options/locale/locale_en-US.ini
context
- If a user tries to create another protected branching rule that
specifies a set of branches already used by another rule, do not allow
it.
- Update the translation accordingly.
- Adds integration test.
- Resolves#2455
Adds a label to Pull Requests that were created using AGit-Flow,
in order to prevent situations where a contributor uses AGit-Flow
to push new changes - only to realize that they did not use AGit-Flow
in the first place, and that they just opened a new PR accidentally
(that was me).
Also intended to raise general awareness about the feature. Some
additional work, such as adding a tooltip, still needs to be
done.
A small typo fix for a comment and (exclusively) formatting fixes
in the copyright header are also included.
Refs: https://codeberg.org/forgejo/forgejo/issues/2433
- Clarify in the description shown in the "Manage SSH Keys" section,
that verified SSH keys can be used as verification for Git commits that
were signed with SSH keys.
- Resolves#2369
Continuation of https://github.com/go-gitea/gitea/pull/25439. Fixes#847
Before:
<img width="1296" alt="image"
src="https://github.com/go-gitea/gitea/assets/32161460/24571ac8-b254-43c9-b178-97340f0dc8a9">
----
After:
<img width="1296" alt="image"
src="https://github.com/go-gitea/gitea/assets/32161460/c60b2459-9d10-4d42-8d83-d5ef0f45bf94">
---
#### Overview
This is the implementation of a requested feature: Contributors graph
(#847)
It makes Activity page a multi-tab page and adds a new tab called
Contributors. Contributors tab shows the contribution graphs over time
since the repository existed. It also shows per user contribution graphs
for top 100 contributors. Top 100 is calculated based on the selected
contribution type (commits, additions or deletions).
---
#### Demo
(The demo is a bit old but still a good example to show off the main
features)
<video src="https://github.com/go-gitea/gitea/assets/32161460/9f68103f-8145-4cc2-94bc-5546daae7014" controls width="320" height="240">
<a href="https://github.com/go-gitea/gitea/assets/32161460/9f68103f-8145-4cc2-94bc-5546daae7014">Download</a>
</video>
#### Features:
- Select contribution type (commits, additions or deletions)
- See overall and per user contribution graphs for the selected
contribution type
- Zoom and pan on graphs to see them in detail
- See top 100 contributors based on the selected contribution type and
selected time range
- Go directly to users' profile by clicking their name if they are
registered gitea users
- Cache the results so that when the same repository is visited again
fetching data will be faster
---------
Co-authored-by: silverwind <me@silverwind.io>
Co-authored-by: hiifong <i@hiif.ong>
Co-authored-by: delvh <dev.lh@web.de>
Co-authored-by: 6543 <6543@obermui.de>
Co-authored-by: yp05327 <576951401@qq.com>
(cherry picked from commit 21331be30cb8f6c2d8b9dd99f1061623900632b9)
- Move the conditions code around, such that the existence of the head
and base is first checked (so a clear error can be given, instead of a
possible server error). This makes it easier to read this code. As the
logic is now grouped together.
- Adds integration testing that simulates the deletion of the base and
head branch and ensures the pull request cannot be opened. The 'normal'
testcase also 'informally' ensures that the previous incorrect condition
is not there, because the branch `base-branch` doesn't exist on the head
repository.
- Resolves#2321
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
If a repository administrator is viewing a repository, and there are
units that can be enabled, display an "Add more..." link that leads to
the repository unit settings page.
The goal here is to allow instances to configure a small set of repo
units to be enabled by default, but also highlight for repo admins that
they can add more.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
This splits out the repository unit settings (formerly "Advanced
settings" under the repository settings page) into their own, separate
page.
The primary reason for this is that the settings page became long and
complicated, with a structure that not always made sense. A secondary
reason is that toggling units on and off should not necessarily be an
"advanced" setting. We want to make doing that easier, and having the
units on their own page helps with that.
This is basically a refactor, there is no new functionality introduced,
just an extra pair of routes for the new page, and the supporting code.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
Previously, the repo wiki was hardcoded to use `master` as its branch,
this change makes it possible to use `main` (or something else, governed
by `[repository].DEFAULT_BRANCH`, a setting that already exists and
defaults to `main`).
The way it is done is that a new column is added to the `repository`
table: `wiki_branch`. The migration will make existing repositories
default to `master`, for compatibility's sake, even if they don't have a
Wiki (because it's easier to do that). Newly created repositories will
default to `[repository].DEFAULT_BRANCH` instead.
The Wiki service was updated to use the branch name stored in the
database, and fall back to the default if it is empty.
Old repositories with Wikis using the older `master` branch will have
the option to do a one-time transition to `main`, available via the
repository settings in the "Danger Zone". This option will only be
available for repositories that have the internal wiki enabled, it is
not empty, and the wiki branch is not `[repository].DEFAULT_BRANCH`.
When migrating a repository with a Wiki, Forgejo will use the same
branch name for the wiki as the source repository did. If that's not the
same as the default, the option to normalize it will be available after
the migration's done.
Additionally, the `/api/v1/{owner}/{repo}` endpoint was updated: it will
now include the wiki branch name in `GET` requests, and allow changing
the wiki branch via `PATCH`.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
(cherry picked from commit d87c526d2a)
