IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
- Move some scripts from `build` to new `tools` dir. Eventually i would
like to move all but let's do it step-by-step.
- Add dir to eslint and move the files into vars.
- Update docs accordingly.
- While updating docs I noticed we were incorrectly having `public/img`
path still in a few places. Replace those with the current
`public/assets/img`.
---------
Co-authored-by: Nanguan Lin <nanguanlin6@gmail.com>
Co-authored-by: Giteabot <teabot@gitea.io>
(cherry picked from commit 095fdd691dd1a7d7748372cc73e7708278c80933)
Move `public/*` to `public/assets/*`
Some old PRs (like #15219) introduced inconsistent directory system.
For example: why the local directory "public" is accessed by
`http://site/assets`? How to serve the ".well-known" files properly in
the public directory?
For convention rules, the "public" directory is widely used for the
website's root directory. It shouldn't be an exception for Gitea.
So, this PR makes the things consistent:
* `http://site/assets/foo` means `{CustomPath}/public/assets/foo`.
* `{CustomPath}/public/.well-known` and `{CustomPath}/public/robots.txt`
can be used in the future.
This PR is also a prerequisite for a clear solution for:
* #21942
* #25892
* discourse.gitea.io: [.well-known path serving custom files behind
proxy?](https://discourse.gitea.io/t/well-known-path-serving-custom-files-behind-proxy/5445/1)
This PR is breaking for users who have custom "public" files (CSS/JS).
After getting approvals, I will update the documents.
----
## ⚠️ BREAKING ⚠️
If you have files in your "custom/public/" folder, please move them to
"custom/public/assets/".
---------
Co-authored-by: 6543 <6543@obermui.de>
Co-authored-by: Giteabot <teabot@gitea.io>
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.
There's a lot of work that has been done on `.dockerignore`:
- #329
- #2927
- #8338
And finally, it has been deleted by #2927.
This is a copy of the `.gitignore`.
Creating a soft link is more elegant, but it may cause trouble to the Windows users.
I have restructured the docker build process entirely, the binary gets
built outside of the docker build command, now we are managing all
dependencies with real Alpine packages and I have dropped features like
socat or the cron daemon.
Signed-off-by: Thomas Boerger <tboerger@suse.de>
* docker: update build script to use glide + make
- docker/build.sh will now use glide to fetch dependencies
- glide is built from source to keep compatibility with arm
(no pre-prebuilt binary for arm)
- docker/build.sh will also now use the provided Makefile
It will generate an error when trying to get git build has as we do
not ship the 88mo .git directory during the build (should not cause
any problem as the variable it sets was not set previously)
* docker: fix docker arm build
- drop gosu version back to 1.7 as gosu binary for armhf is broken
- see tianon/gosu#19
* docker: update gosu to 1.9
Signed-off-by: Jean-Philippe Roemer <jp@roemer.im>
- Now using a setup script before starting the app. The separation of
the run script and the setup script will make service initialisation a
little bit clearer
- Now calling start.sh script as ENTRYPOINT and S6 as CMD. This way
when running the container with just a shell script, the start.sh
script will be launched before, making debugging easier
- Added note about `.dockerignore` ignored during Docker Hub Automated
Build
- VOLUME for ‘/data’
- Usage of S6 as PID 1 Process
- Usage of ‘socat’ so linked container (like databases) are binded to
localhost
- OpenSSH, Socat Link and Gogs are supervised using S6
- Size of container reduced to ~75Mo
