(cherry picked from commit 20b5669269)
(cherry picked from commit 1574643a6a)
Update semantic version according to specification
(cherry picked from commit 22510f4130)
Mise à jour de 'Makefile'
(cherry picked from commit c3d85d8409)
(cherry picked from commit 5ea2309851)
(cherry picked from commit ec5217b9d1)
(cherry picked from commit 14f08e364b)
(cherry picked from commit b4465c67b8)
[API] [SEMVER] replace number with version
(cherry picked from commit fba48e6497)
(cherry picked from commit 532ec5d878)
[API] [SEMVER] [v1.20] less is replaced by css
(cherry picked from commit 01ca3a4f42)
(cherry picked from commit 1d928c3ab2)
(cherry picked from commit a39dc804cd)
Conflicts:
webpack.config.js
(cherry picked from commit adc68578b3)
(cherry picked from commit 9b8d98475f)
(cherry picked from commit 2516103974)
(cherry picked from commit 18e6287963)
(cherry picked from commit e9694e67ab)
(cherry picked from commit a9763edaf0)
(cherry picked from commit e2b550f4fb)
(cherry picked from commit 2edac36701)
[API] Forgejo API /api/forgejo/v1 (squash)
Update semver as v1.20 is entering release candidate mode
(cherry picked from commit 4995098ec3)
(cherry picked from commit 578ccfdd27)
(cherry picked from commit 1bf6ac0952)
(cherry picked from commit 2fe16b2bfe)
(cherry picked from commit 7cd9d027ee)
Refs: https://codeberg.org/forgejo/website/pulls/230
(cherry picked from commit 87d56bf6c7)
[CI] Forgejo Actions based release process (squash)
base64 -w0 to avoid wrapping when the doer name is long as it creates
a broken config.json
(cherry picked from commit 9efdc27e49)
[CI] Forgejo Actions based release process (squash) generate .xz files and sources
Generate .xz files
Check .sha256
Generate the source tarbal
(cherry picked from commit 7afec520c4)
[CI] Forgejo Actions based release process (squash) release notes
(cherry picked from commit d8f4f4807b)
[CI] Forgejo Actions based release process (squash) publish and sign release
(cherry picked from commit a52778c747)
(cherry picked from commit cf2ec62740)
[CI] Forgejo Actions based release process (squash) version
use Actions environment variables in Makefile (#25319) (#25318)
uses Actions variable to determine the version. But Forgejo builds
happen in a container where they are not available. Do not use them.
Also verify the version of the binary is as expected for sanity check.
(cherry picked from commit 6decf111a1)
(cherry picked from commit 206d0b3886)
[CI] read STORED_VERSION_FILE if available
(cherry picked from commit af74085ebf)
[CI] backward compatible executable compilation
Add a new static-executable target to use in Dockerfiles and restore
the $(EXECUTABLE) target to what it was before to for backward
compatibility.
The release process now builds static executables instead of
dynamically linked ones which makes them more portable. It changes the
requirements at compile time and is not backward compatible. In
particular it may break packaging that rely on the target that
currently creates a dynamically linked executable.
(cherry picked from commit 84d02a174a)
(cherry picked from commit 854be47328)
[CI] Forgejo Actions based release process (squash) doc / ca / verbosity
- Document workflow
- Increase verbosity if VERBOSE=true
- Download the Certificate Authority if behind the VPN
(cherry picked from commit 168d5d5869)
(cherry picked from commit 8756c9a72a)
(cherry picked from commit c2a7aaeee8)
(cherry picked from commit 6b6007fbce)
(cherry picked from commit 63608a221e)
(cherry picked from commit 5cfe60baa7)
(cherry picked from commit 2af4c73d12)
(cherry picked from commit 1985959bfe)
(cherry picked from commit 880424c77e)
(cherry picked from commit c78a861d1b)
(cherry picked from commit 25c1227011)
(cherry picked from commit 7195e894ee)
(cherry picked from commit cf15153873)
(cherry picked from commit 9bee773c95)
(cherry picked from commit 581c3060da)
(cherry picked from commit bf550f9b2c)
(cherry picked from commit b570eca0b9)
[CI] implementation: Woodpecker based CI (squash)
Upgrade xgo to Go v1.20 for building binaries
(cherry picked from commit 6308c776b6)
[CI] v1.20: switch PR check from Woodpecker CI to Forgejo Actions
The PR checks for v1.19 still rely on Woodpecker CI. Keeping
.woodpecker in v1.20 while both Woodpecker CI & Forgejo Actions are
enabled would dupicate the checks.
The release process in releases remains Woodpecker CI.
(cherry picked from commit 93e42f3f53)
(cherry picked from commit 599c5162ad)
(cherry picked from commit 6f8b723a55)
(cherry picked from commit e238d7d72f)
(cherry picked from commit 2258fb575b)
(cherry picked from commit 52195d9456)
- Update all JS dependencies
- Enable `declaration-property-unit-disallowed-list` to forbid `em` on
`line-height`
- Rename dependency update targets to `update-js` and `update-py` and
document them
- Remove margin on Asciicast viewer
- Tested Swagger, Katex, Asciicast
<img width="1243" alt="Screenshot 2023-06-27 at 19 51 05"
src="https://github.com/go-gitea/gitea/assets/115237/2d2722a0-2aa7-4f4c-b8bd-17e1f3637b78">
[updates](https://github.com/silverwind/updates) now supports poetry as
well so we can use it for a new `make poetry-update` to update all
poetry dependencies.
As title, this is how it was inferred before
e24f651c86/Makefile (L83-L84)
We moved to actions, however `GITEA_VERSION` should still work to use
`VERSION`
Signed-off-by: jolheiser <john.olheiser@gmail.com>
The [docker/build-push-action@v2
action](https://github.com/docker/build-push-action) by default ignores
the checkout created using the actions/checkout@v2 action. When you pass
a git build context to docker build, it wouldn't include the .git
directory.
By passing `context: .` to the build step then it'll use the Actions git
context which includes the git fetch from the earlier step.
So I found this [linter](https://github.com/Riverside-Healthcare/djlint)
which features a mode for go templates, so I gave it a try and it did
find a number of valid issue, like unbalanced tags etc. It also has a
number of bugs, I had to disable/workaround many issues.
Given that this linter is written in python, this does add a dependency
on `python` >= 3.8 and `poetry` to the development environment to be
able to run this linter locally.
- `e.g.` prefixes on placeholders are removed because the linter had a
false-positive on `placeholder="e.g. cn=Search"` for the `attr=value`
syntax and it's not ideal anyways to write `e.g.` into a placeholder
because a placeholder is meant to hold a sample value.
- In `templates/repo/settings/options.tmpl` I simplified the logic to
not conditionally create opening tags without closing tags because this
stuff confuses the linter (and possibly the reader as well).
It's been disabled by default since 1.17
(https://github.com/go-gitea/gitea/pull/18914), and it never really
delivered any benefit except being another cache layer that has its own
unsolved invalidation issues. HTTP cache works, we don't need two cache
layers at the browser for assets.
## ⚠️ BREAKING
You can remove the config `[ui].USE_SERVICE_WORKER` from your `app.ini`
now.
Inspired by
https://github.com/go-gitea/gitea/pull/24530#issuecomment-1558815301
This PR use a file filter action to do different CI jobs according
changed files types. All types are defined in
`.github/file-filters.yml`. Now there are 4 types, `docs`, `backend`,
`frontend` and `build`. Then if a PR only changed docs files, those CI
jobs which passed the conditions will run, and other types are also like
this.
---------
Co-authored-by: silverwind <me@silverwind.io>
- Remove actions name where command is descriptive enough
- Use kebab-case instead of snake-case for step names
- Use shorter job names because to make PR checks more readable
- Remove duplicate `checks-backend`
---------
Co-authored-by: Yarden Shoham <git@yardenshoham.com>
Proposal found here: https://github.com/go-gitea/gitea/issues/23654
TODO: make non-breaking (can we publish docker image using dev and
nightly prefix? at same time). if anyone has advice please comment :)
If this PR is merged, then I can add redirects to the downloads site.
- Update all tool dependencies to latest tag
- Remove unused errcheck, it is part of golangci-lint
- Include main.go in air
- Enable wastedassign again now that it's
[generics-compatible](https://github.com/golangci/golangci-lint/pull/3689)
- Restructured lint targets to new `lint-*` namespace
- Add new Make target `lint-md`
- Add new Drone pipeline `compliance-docs`
- Add `*.md` to docs exclusion/inclusion
- Consistently quote `path.include` and `path.exclude` statements in
YAML
* Clean the "tools" directory. The "tools" directory contains only two
files, move them.
* The "external_renderer.go" works like "cat" command to echo Stdin to
Stdout , to help testing.
* The `// gobuild: external_renderer` is incorrect, there should be no
space: `//gobuild: external_renderer`
* The `fmt.Print(os.Args[1])` is not a well-defined behavior, and it's
never used.
* The "watch.sh" is for "make watch", it's somewhat related to "build"
* After this PR, there is no "tools" directory, the project root
directory looks slightly simpler than before.
* Remove the legacy "contrib/autoboot.sh", there is no
"gogs_supervisord.sh"
* Remove the legacy "contrib/mysql.sql", it's never mentioned anywhere.
* Remove the legacy "contrib/pr/checkout.go", it has been broken for
long time, and it introduces unnecessary dependencies of the main code
base.
Refactored `deps-docs` out of `docs` because #23629 broke Gitpod's docs
setup (which grepped to get the hugo install command).
Now `make deps` really installs everything to develop (includes `docs`).
- **Installation**: includes how to install Gitea and related other
tools, also includes upgrade Gitea
- **Administration**: includes how to configure Gitea, customize Gitea
and manage Gitea instance out of Gitea admin UI
- **Usage**: includes how to use Gitea's functionalities. A sub
documentation is about packages, in future we could also include CI/CD
and others.
- **Development**: includes how to integrate with Gitea's API, how to
develop new features within Gitea
- **Contributing**: includes how to contribute code to Gitea
repositories.
After this is merged, I think we can have a sub-documentation of `Usage`
part named `Actions` to describe how to use Gitea actions
---------
Co-authored-by: John Olheiser <john.olheiser@gmail.com>
Ran most of the Less files through the Less compiler and Prettier and
then followed up with a round of manual fixes.
The Less compiler had unfortunately stripped all `//` style comments
that I had to restore (It did preserve `/* */` comments). Other fixes
include duplicate selector removal which were revealed after the
transpilation and which weren't caught by stylelint before but now are.
Fixes: https://github.com/go-gitea/gitea/issues/15565
hardcode the version of test_env we use in docker, so that we can use
different major versions of golang between versions of Gitea
---------
Co-authored-by: Lauris BH <lauris@nix.lv>
- This PR attempts to split our various DB tests into separate
pipelines.
- It splits up some of the extra feature-related tests rather than
having most of them in the MySQL test.
- It disables the race detector for some of the pipelines as well, as it
can cause slower runs and is mostly redundant when the pipelines just
swap DBs.
- It builds without SQLite support for any of the non-SQLite pipelines.
- It moves the e2e test to using SQLite rather than PG (partially
because I moved the minio tests to PG and that mucked up the test
config, and partially because it avoids another running service)
- It splits up the `go mod download` task in the Makefile from the tool
installation, as the tools are only needed in the compliance pipeline.
(Arguably even some of the tools aren't needed there, but that could be
a follow-up PR)
- SQLite is now the only arm64 pipeline, moving PG back to amd64 which
can leverage autoscaler
Should resolve #22010 - one thing that wasn't changed here but is
mentioned in that issue, unit tests are needed in the same pipeline as
an integration test in order to form a complete coverage report (at
least as far as I could tell), so for now it remains in a pipeline with
a DB integration test.
Please let me know if I've inadvertently changed something that was how
it was on purpose.
---
I will say sometimes it's hard to pin down the average time, as a
pipeline could be waiting for a runner for X minutes and that brings the
total up by X minutes as well, but overall this does seem to be faster
on average.
---------
Signed-off-by: jolheiser <john.olheiser@gmail.com>
Co-authored-by: techknowlogick <techknowlogick@gitea.io>
Using `touchstart` for `click` events is a black magic for mobile
browsers (Google: `fastclick`).
However, it causes many UX problems if the fastclick is used without
careful design.
Fomantic UI uses this fastclick for its `dimmer` and `dropdown`, it
makes mobile users feel strange when they "touch" the dropdown menu.
This PR uses a simple patch to fix that behavior. Then the Fomantic
dropdown only uses `click` for click events.
This PR is simple enough and won't cause hidden bugs even if the patch
doesn't work. In the future, if there are more patches for Fomantic UI,
the patches could be placed in a directory like
`web_src/fomantic/patches/001-fix-click-touchstart`, etc.
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
This PR does a bulk update of a lot of our go deps.
I have not included nektos/act and xorm for the following reasons:
* Xorm updates can sometimes be complex and I'd rather do that in a
separate PR
* I think people more update with the actions code should double check
that the latest nektos/act library works correctly.
---------
Signed-off-by: Andrew Thornton <art27@cantab.net>
Co-authored-by: techknowlogick <techknowlogick@gitea.io>
Fix #22370 and more.
Before Go 1.19, the `netgo` tag for Windows does nothing.
But Go 1.19 rewrite the net package code for Windows DNS, and there is a
bug:
* https://github.com/golang/go/issues/57757
This PR just removes the `netgo` tag for Windows build, then the Gitea
for Windows can have the old DNS behavior.
Since #20218 introduced internal watching template, template watching
should be removed from `air`. This will prevent restart the whole server
once the template files changed to speed up developing when using `make
watch`.
To ensure `make watch` will reuse template watching, this PR introduced
a new ENV `GITEA_RUN_MODE` to make sure `make watch` will always run in
a dev mode of Gitea so that template watching will open.
This PR also added more exclude testdata directories.
`fmt-check` now simply does `fmt` before and relies on `git diff` like
other checks like 'tidy-check' already do, so we can remove the argument
in the tool that handles printing changed files.
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
Co-authored-by: zeripath <art27@cantab.net>
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
Even if we are not bundling with `vite` yet, we can use `vitest` in
place of Jest which brings a few benefits like not requiring to use
`NODE_OPTIONS` to run and having sane module resolution.
It's possible to also use `jest-extended` with vitest, but I opted to
not do so for now because it brings heavyweight dependencies and it was
trivial to just rewrite the affected matchers to be compatible.
This PR also removes 153 JS dependencies, which is certainly nice.
Co-authored-by: 6543 <6543@obermui.de>
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
Running it as part of the build is really unnecessary because we have a
valid output file in the repo and assuming go dependencies do not change
unless go.mod also changes, tidy really is the best target to run the
license generation after.
Also, regenerate the file as I missed to do so during the chroma update,
and mark all json files in assets as generated.
- Update all JS dependencies and playwright image
- Add new eslint rules, enable a few more, fix issues
- Regenerate SVGs
- Tested Vue and Swagger
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
We can not have the `frontend` target depend on golang because of they
way drone is set up. Move the `go-licenses` generation back into `tidy`
where it will now also be checked for consistency during `tidy-check`.
(I assume all `main` branch builds should currently fail [like
this](https://drone.gitea.io/go-gitea/gitea/60244/1/11)).
The reasony why it shouldn't be treated the same as for example `go
generate` is because output files are checked in. tidy is imho the
optimal target to run this after.
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
