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)
* use go1.18 to build gitea& update min go version to 1.17
* bump in a few more places
* add a few simple tests for isipprivate
* update go.mod
* update URL to https://go.dev/dl/
* golangci-lint
* attempt golangci-lint workaround
* change version
* bump fumpt version
* skip strings.title test
* go mod tidy
* update tests as some aren't private??
* update tests
* Upgrade alpine to 3.15
* Add executability test to entrypoint for too old dockers
Signed-off-by: Andrew Thornton <art27@cantab.net>
* Update docker/rootless/usr/local/bin/docker-entrypoint.sh
Co-authored-by: zeripath <art27@cantab.net>
Too many docker users are caught out by the default location for the
app.ini file being environment dependent so that when they docker exec
into the container the gitea commands do not work properly and require
additional -c arguments to correctly pick up the configuration.
This PR simply shadows the gitea binary using variants of the FHS
compatible script to make the command gitea have the default locations
by default.
Fix#14468
Reference #17497
Reference #12082
Reference #8941
... amongst others ...
Replace #17501
Signed-off-by: Andrew Thornton <art27@cantab.net>
Run chmod on the executables and the entrypoint when copying them to the
docker in dockerfile.
Signed-off-by: Andrew Thornton <art27@cantab.net>
Co-authored-by: 6543 <6543@obermui.de>
Co-authored-by: Norwin <noerw@users.noreply.github.com>
Co-authored-by: delvh <dev.lh@web.de>
* Add environment-to-app.ini routine
* Call environment-to-ini in docker setup scripts
* Automatically convert section vars to lower case to match documentation
* Remove git patch instructions
* Add env variable documentation to Install Docker
* Dockerfile: Support socat use cases
In some contexts it is necessary to provide access to Gitea via TCP ports and unix sockets.
Gitea (`gitea web`) can be configured to listen for connections via unix-socket or TCP port, but not both.
When Gitea is installed to the host this limitation can be worked around by installing socat on the host.
When running Gitea from a container this limitation cannot be workaround.
Add socat to Gitea container.
* Removed version
Co-authored-by: techknowlogick <techknowlogick@gitea.io>
* go1.15
* update makefile xgo version
* fix vet issue
* update docs to version of go in use
* add TODO for asyncpreemptoff
Co-authored-by: Lauris BH <lauris@nix.lv>
* Create docker/manifest/base.yml
serve as base for build docker image for most platform (386,amd64,arm,arm64)
* Add make task docker-multi-arch-push-manifest
To update references of a multi-arch image on docker registry.
* Use SED_INPLACE generic sed command
* Delete Dockerfile.aarch64
Delete Dockerfile.rpi
* Use gitea/gitea-base as base
and replace deprecated MAINTAINER by LABEL (https://docs.docker.com/engine/reference/builder/#maintainer-deprecated)
* Fix rebase
* Use sapk/gitea-base as base
* Split makefile for docker
* Fix version to v3.6
Could use in later version edge of alpine official library that support multi-arch for armhf.
* Remove sapk/gitea-base and use directly new official alpine multi-arch
* Add `gettext` dependencies as we need `envsubst` command;
* Modified s6's gitea setup script, instead of `cp` the template if no
`app.ini` exist, it will substitude the envvars and generate the new
`app.ini`;
* Make `/docker/etc/templates/app.ini` a template contains environment
variables;
Signed-off-by: Tao Wang <twang2218@gmail.com>
Loïc Dachary