Now that https://github.com/techknowlogick/xgo/issues/163 is resolved,
we can bump these.
It seems there is no way to dry-run this, so we may only notice issues
next release, but I don't expect any.
similar to #24314, this moves drone cron pipelines to (GitHub) Actions.
As these are mostly compatible with Gitea Actions, when we start to
dogfood, these will already be migrated.
I also removed the discord notify pipeline, as it hasn't been working
for several months.
Move drone cron pipelines to (GitHub) Actions. As these are mostly
compatible with Gitea Actions, when we start to dogfood, these will
already be migrated.
- 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
The `safe.directory` setting was not executed for pull requests, which
made subsequent `deps-backend` target fail at `go mod download`. To fix
it, split thep and perform the git config unconditionally.
Example: https://drone.gitea.io/go-gitea/gitea/69477/4/3
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
This skips all testing-* pipelines on push to main or release/*
branches. This decreases the total build time on those, as in theory
they should already be run for PRs before merging.
Fixes https://github.com/go-gitea/gitea/issues/22011
---------
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
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 switches Docker builds to use build kit which is less prone to
error than legacy docker-in-docker building. It also switches back to
using the upstream docker image again now that it has been updated to a
version that supports alpine 3.14+
Co-authored-by: John Olheiser <john.olheiser@gmail.com>
- 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>
Since drone plugin
https://github.com/meltwater/drone-convert-pathschanged/ enabled, we can
filter event with path in drone.
Building docs will now only be triggered when documentations changed.
---------
Co-authored-by: Jason Song <i@wolfogre.com>
- Update all JS dependencies
- Add new eslint rules
- Rebuild SVGs
- Tested citation and build
SVG changes are because of https://github.com/primer/octicons/pull/883.
Co-authored-by: techknowlogick <techknowlogick@gitea.io>
closes#13585fixes#9067fixes#2386
ref #6226
ref #6219fixes#745
This PR adds support to process incoming emails to perform actions.
Currently I added handling of replies and unsubscribing from
issues/pulls. In contrast to #13585 the IMAP IDLE command is used
instead of polling which results (in my opinion 😉) in cleaner code.
Procedure:
- When sending an issue/pull reply email, a token is generated which is
present in the Reply-To and References header.
- IMAP IDLE waits until a new email arrives
- The token tells which action should be performed
A possible signature and/or reply gets stripped from the content.
I added a new service to the drone pipeline to test the receiving of
incoming mails. If we keep this in, we may test our outgoing emails too
in future.
Co-authored-by: silverwind <me@silverwind.io>
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
- Don't rely on obscure docker images like `plugins/hugo`
- Lock down `hugo` to same version the image had used
- Remove unnecessary verbosity in `trans-copy`
- Rename `trans-copy` to `trans-copy.sh`
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
Co-authored-by: John Olheiser <john+github@jolheiser.com>
Co-authored-by: techknowlogick <techknowlogick@gitea.io>
updating libcurl fixes the mismatch between curl and libcurl
Signed-off-by: jolheiser <john.olheiser@gmail.com>
Co-authored-by: silverwind <me@silverwind.io>
- Update all JS dependencies to latest version
- Enable unicorn/prefer-node-protocol and autofix issues
- Regenerate SVGs
- Add some comments to eslint rules
- Tested build, Mermaid and Katex rendering
I don't know how to test this so I'll explain my thought process:
After a discussion with @techknowlogick in
cda2c38f4a
I saw the CI config has this block:
cda2c38f4a/.drone.yml (L618-L630)
I don't know much about Drone but after looking at
[appleboy/drone-git-push](https://github.com/appleboy/drone-git-push)'s
source code, I think each setting becomes an environment variable (e.g.
`remote` to `PLUGIN_REMOTE`, `commit_message` to `PLUGIN_COMMIT_MESSAGE`
etc...). Take a look at the code block loading the author info:
a69878c006/main.go (L32-L42)
Two environment variables are listed for each setting. This PR forces
both to have the same value.
Signed-off-by: Yarden Shoham <hrsi88@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>
This removes the JS dependency in the checks pipeline. JSON output is
different because the previous JS did indent the license data
differently and a JSON key was changed, but the end result is the same
as it gets re-indented by wepack.
Co-authored-by: 6543 <6543@obermui.de>
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
Co-authored-by: zeripath <art27@cantab.net>
`make go-licenses` will generate `assets/go-licenses.json` which is then included in the webpack build.
This step depends on both go and node being present, so unfortunately, I could not automate the generation by hooking it up to `tidy` as that target is triggered on CI where we do not have a docker image with both go an node.
It should be ran from time to time, ideally after each go mod update.
