- Use TXT records in order to determine the latest available version.
- This addresses a valid privacy issue, as with HTTP requests the server
can keep track(estimated) of how many instances are using Forgejo, with
DNS that's basically not possible as the server will never receive any
data, as the only ones receiving data are DNS resolvers.
(cherry picked from commit 0baefb546a)
(cherry picked from commit e8ee41880b)
(cherry picked from commit 7eca4f3bf1)
(cherry picked from commit 6dde3992dc)
(cherry picked from commit fb3a37fbfc)
(cherry picked from commit 8304af1e9d)
(cherry picked from commit 0543a7d12a)
(cherry picked from commit c3a22933b7)
(cherry picked from commit e243707694)
(cherry picked from commit 7eb6d1bcf7)
(cherry picked from commit 1d7b9535cd)
(cherry picked from commit 05920dce67)
(cherry picked from commit f173f27d7c)
(cherry picked from commit 90e1c9340e)
(cherry picked from commit de68610ea7)
(cherry picked from commit 8d5757ea04)
(cherry picked from commit c7a7fff316)
(cherry picked from commit 39ac8b8fc1)
(cherry picked from commit 9889203301)
[PRIVACY]: Adjust update checker description
- Resolves #323
- Adjust the description of the update check function on the
installation page to describe the privacy method instead of the HTTP
method by checking gitea.io
(cherry picked from commit 61eae5b105)
(cherry picked from commit 091def20a1)
(cherry picked from commit d5d11bf45a)
(cherry picked from commit 71863d4707)
(cherry picked from commit 11ece4aab1)
(cherry picked from commit afdd7e714f)
(cherry picked from commit 39170e2f1d)
(cherry picked from commit 4b3a52aab8)
(cherry picked from commit 9d763c5fc8)
(cherry picked from commit 638db15482)
- This is being disabled as it will weekly connect to a domain.
- This only affects existing installations, as new installations will
have a explicit value being written into app.ini due to https://github.com/go-gitea/gitea/pull/21655
(cherry picked from commit cd0b8b6852)
(cherry picked from commit 58d43867ca)
(cherry picked from commit f290b91e50)
(cherry picked from commit 5bd6d75554)
(cherry picked from commit e5d0abb592)
(cherry picked from commit 4b381ce77e)
(cherry picked from commit b6a9b1390d)
(cherry picked from commit 3674362871)
(cherry picked from commit af0f606fc1)
(cherry picked from commit 49560da6fb)
(cherry picked from commit ca06e27c5b)
(cherry picked from commit 163df86df5)
(cherry picked from commit 0391c6ae42)
(cherry picked from commit f282f2d42f)
(cherry picked from commit 68d31cf247)
(cherry picked from commit cfd4a479e9)
(cherry picked from commit add969bdf6)
(cherry picked from commit c0f3f1f1e7)
(cherry picked from commit f11dca9090)
(cherry picked from commit 283810387f)
(cherry picked from commit 08af1f0ea8)
(cherry picked from commit 1c1a6da319)
(cherry picked from commit c1444bae65)
(cherry picked from commit 6361df634b)
(cherry picked from commit cc8bb3f946)
(cherry picked from commit c7ae4411fd)
(cherry picked from commit f73f4eef02)
(cherry picked from commit 2122896e85)
This field adds the possibility to set the update date when modifying
an issue through the API.
A 'NoAutoDate' in-memory field is added in the Issue struct.
If the update_at field is set, NoAutoDate is set to true and the
Issue's UpdatedUnix field is filled.
That information is passed down to the functions that actually updates
the database, which have been modified to not auto update dates if
requested.
A guard is added to the 'EditIssue' API call, to checks that the
udpate_at date is between the issue's creation date and the current
date (to avoid 'malicious' changes). It also limits the new feature
to project's owners and admins.
(cherry picked from commit c524d33402)
Add a SetIssueUpdateDate() function in services/issue.go
That function is used by some API calls to set the NoAutoDate and
UpdatedUnix fields of an Issue if an updated_at date is provided.
(cherry picked from commit f061caa655)
Add an updated_at field to the API calls related to Issue's Labels.
The update date is applied to the issue's comment created to inform
about the modification of the issue's labels.
(cherry picked from commit ea36cf80f5)
Add an updated_at field to the API call for issue's attachment creation
The update date is applied to the issue's comment created to inform
about the modification of the issue's content, and is set as the
asset creation date.
(cherry picked from commit 96150971ca)
Checking Issue changes, with and without providing an updated_at date
Those unit tests are added:
- TestAPIEditIssueWithAutoDate
- TestAPIEditIssueWithNoAutoDate
- TestAPIAddIssueLabelsWithAutoDate
- TestAPIAddIssueLabelsWithNoAutoDate
- TestAPICreateIssueAttachmentWithAutoDate
- TestAPICreateIssueAttachmentWithNoAutoDate
(cherry picked from commit 4926a5d7a2)
Add an updated_at field to the API call for issue's comment creation
The update date is used as the comment creation date, and is applied to
the issue as the update creation date.
(cherry picked from commit 76c8faecdc)
Add an updated_at field to the API call for issue's comment edition
The update date is used as the comment update date, and is applied to
the issue as an update date.
(cherry picked from commit cf787ad7fd)
Add an updated_at field to the API call for comment's attachment creation
The update date is applied to the comment, and is set as the asset
creation date.
(cherry picked from commit 1e4ff424d3)
Checking Comment changes, with and without providing an updated_at date
Those unit tests are added:
- TestAPICreateCommentWithAutoDate
- TestAPICreateCommentWithNoAutoDate
- TestAPIEditCommentWithAutoDate
- TestAPIEditCommentWithNoAutoDate
- TestAPICreateCommentAttachmentWithAutoDate
- TestAPICreateCommentAttachmentWithNoAutoDate
(cherry picked from commit da932152f1)
Pettier code to set the update time of comments
Now uses sess.AllCols().NoAutoToime().SetExpr("updated_unix", ...)
XORM is smart enough to compose one single SQL UPDATE which all
columns + updated_unix.
(cherry picked from commit 1f6a42808d)
Issue edition: Keep the max of the milestone and issue update dates.
When editing an issue via the API, an updated_at date can be provided.
If the EditIssue call changes the issue's milestone, the milestone's
update date is to be changed accordingly, but only with a greater
value.
This ensures that a milestone's update date is the max of all issue's
update dates.
(cherry picked from commit 8f22ea182e)
Rewrite the 'AutoDate' tests using subtests
Also add a test to check the permissions to set a date, and a test
to check update dates on milestones.
The tests related to 'AutoDate' are:
- TestAPIEditIssueAutoDate
- TestAPIAddIssueLabelsAutoDate
- TestAPIEditIssueMilestoneAutoDate
- TestAPICreateIssueAttachmentAutoDate
- TestAPICreateCommentAutoDate
- TestAPIEditCommentWithDate
- TestAPICreateCommentAttachmentAutoDate
(cherry picked from commit 961fd13c55)
(cherry picked from commit d52f4eea44)
Just like `models/unittest`, the testing helper functions should be in a
separate package: `contexttest`
And complete the TODO:
> // TODO: move this function to other packages, because it depends on
"models" package
Cargo registry-auth feature requires config.json to have a property
auth-required set to true in order to send token to all registry
requests.
This is ok for git index because you can manually edit the config.json
file to add the auth-required, but when using sparse
(setting index url to
"sparse+https://git.example.com/api/packages/{owner}/cargo/"), the
config.json is dynamically rendered, and does not reflect changes to the
config.json file in the repo.
I see two approaches:
- Serve the real config.json file when fetching the config.json on the
cargo service.
- Automatically detect if the registry requires authorization. (This is
what I implemented in this PR).
What the PR does:
- When a cargo index repository is created, on the config.json, set
auth-required to wether or not the repository is private.
- When the cargo/config.json endpoint is called, set auth-required to
wether or not the request was authorized using an API token.
The web context (modules/context.Context) is quite complex, it's
difficult for the callers to initialize correctly.
This PR introduces a `NewWebContext` function, to make sure the web
context have the same behavior for different cases.
- Resolves https://codeberg.org/forgejo/forgejo/issues/580
- Return a `upload_field` to any release API response, which points to
the API URL for uploading new assets.
- Adds unit test.
- Adds integration testing to verify URL is returned correctly and that
upload endpoint actually works
---------
Co-authored-by: Gusted <postmaster@gusted.xyz>
Replace #22751
1. only support the default branch in the repository setting.
2. autoload schedule data from the schedule table after starting the
service.
3. support specific syntax like `@yearly`, `@monthly`, `@weekly`,
`@daily`, `@hourly`
## How to use
See the [GitHub Actions
document](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#schedule)
for getting more detailed information.
```yaml
on:
schedule:
- cron: '30 5 * * 1,3'
- cron: '30 5 * * 2,4'
jobs:
test_schedule:
runs-on: ubuntu-latest
steps:
- name: Not on Monday or Wednesday
if: github.event.schedule != '30 5 * * 1,3'
run: echo "This step will be skipped on Monday and Wednesday"
- name: Every time
run: echo "This step will always run"
```
Signed-off-by: Bo-Yi.Wu <appleboy.tw@gmail.com>
---------
Co-authored-by: Jason Song <i@wolfogre.com>
Co-authored-by: techknowlogick <techknowlogick@gitea.io>
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
- Add a new `CreateSecretOption` struct for creating secrets
- Implement a `CreateOrgSecret` function to create a secret in an
organization
- Add a new route in `api.go` to handle the creation of organization
secrets
- Update the Swagger template to include the new `CreateOrgSecret` API
endpoint
---------
Signed-off-by: appleboy <appleboy.tw@gmail.com>
## Archived labels
This adds the structure to allow for archived labels.
Archived labels are, just like closed milestones or projects, a medium to hide information without deleting it.
It is especially useful if there are outdated labels that should no longer be used without deleting the label entirely.
## Changes
1. UI and API have been equipped with the support to mark a label as archived
2. The time when a label has been archived will be stored in the DB
## Outsourced for the future
There's no special handling for archived labels at the moment.
This will be done in the future.
## Screenshots
![image](https://github.com/go-gitea/gitea/assets/80308335/208f95cd-42e4-4ed7-9a1f-cd2050a645d4)
![image](https://github.com/go-gitea/gitea/assets/80308335/746428e0-40bb-45b3-b992-85602feb371d)
Part of https://github.com/go-gitea/gitea/issues/25237
---------
Co-authored-by: delvh <dev.lh@web.de>
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
Fix #26129
Replace #26258
This PR will introduce a transaction on creating pull request so that if
some step failed, it will rollback totally. And there will be no dirty
pull request exist.
---------
Co-authored-by: Giteabot <teabot@gitea.io>
Until now expired package data gets deleted daily by a cronjob. The
admin page shows the size of all packages and the size of unreferenced
data. The users (#25035, #20631) expect the deletion of this data if
they run the cronjob from the admin page but the job only deletes data
older than 24h.
This PR adds a new button which deletes all expired data.
![grafik](https://github.com/go-gitea/gitea/assets/1666336/b3e35d73-9496-4fa7-a20c-e5d30b1f6850)
---------
Co-authored-by: silverwind <me@silverwind.io>
Follow #25229
Copy from
https://github.com/go-gitea/gitea/pull/26290#issuecomment-1663135186
The bug is that we cannot get changed files for the
`pull_request_target` event. This event runs in the context of the base
branch, so we won't get any changes if we call
`GetFilesChangedSinceCommit` with `PullRequest.Base.Ref`.
I noticed that `issue_service.CreateComment` adds transaction operations
on `issues_model.CreateComment`, we can merge the two functions and we
can avoid calling each other's methods in the `services` layer.
Co-authored-by: Giteabot <teabot@gitea.io>
- The user renaming function has zero test coverage.
- This patch brings that up to speed to test for various scenarios and
ensure that in a normal workflow the correct things has changed to their
respective new value. Most scenarios are to ensure certain things DO NOT
happen.
(cherry picked from commit 5b9d34ed11)
Refs: https://codeberg.org/forgejo/forgejo/pulls/1156
Co-authored-by: Gusted <postmaster@gusted.xyz>
- Just to get 100% coverage on services/wiki/wiki_path.go, nothing
special. This is just an formality.
(cherry picked from commit 6b3528920f)
Refs: https://codeberg.org/forgejo/forgejo/pulls/1156
Co-authored-by: Gusted <postmaster@gusted.xyz>
In the original implementation, we can only get the first 30 records of
the commit status (the default paging size), if the commit status is
more than 30, it will lead to the bug #25990. I made the following two
changes.
- On the page, use the ` db.ListOptions{ListAll: true}` parameter
instead of `db.ListOptions{}`
- The `GetLatestCommitStatus` function makes a determination as to
whether or not a pager is being used.
fixed #25990
The API should only return the real Mail of a User, if the caller is
logged in. The check do to this don't work. This PR fixes this. This not
really a security issue, but can lead to Spam.
---------
Co-authored-by: silverwind <me@silverwind.io>
Attemp fix: #25744
Fixing the log level when we delete any repo then we get error hook not
found by id. That should be warn level to reduce the noise in the logs.
---------
Co-authored-by: delvh <dev.lh@web.de>