Add cache to container build

[TheFox0x7]

add mount cache directives to container builds, which speeds up local builds bypassing node and go package download entirely on second build and caching go compilation.
drop job level split on regular/rootless, which allows to reuse the previously made stage for rootless, skipping duplicate builds in CI.

[TheFox0x7]

replaces #34876 and #27998 to a lesser degree.

I've tried to trim down CI time further but I can either optimize for local or CI builds because dockers caching system allows to push layers to registry but it does not allow to share mounted cache in any way. I've tried using one action to do so but it did not work at all and maybe for the better as juggling the cache wouldn't be too fun if something went wrong.

It would be possible to optimize for layers here (which I've sort of done) and have them pushed to registry on nightly builds then pulled during every other one but it then removes the mountable cache completely as when both are used they are unreliable (cache is empty and layers apply as if it worked).

[silverwind]

Just add this to the Dockerfiles instead:

LABEL org.opencontainers.image.authors="maintainers@gitea.io"

Ref: https://docs.docker.com/reference/build-checks/maintainer-deprecated/

[silverwind]

Note, Dockerfiles do already have a maintainer label:

gitea/Dockerfile

Line 45 in 8085c75

LABEL maintainer="maintainers@gitea.io"

It's probably better to use org.opencontainers.image.authors instead, but definitely not two labels for the same thing.

[TheFox0x7]

I moved it to tag generation to avoid having implicitly marking user built containers as maintained by gitea, but I can move back into the container if it's not a concern.

[silverwind]

Hmm makes sense your way I guess. Would just like to avoid duplication.

[wxiaoguang]

By the way, to speed up the "github actions release", I can see a much faster approach:

1. Build release binaries first (they will be released to https://dl.gitea.com/gitea/)
2. Use these pre-built binaries and just copy them into the container image, no need to build anymore.

(The container build cache can still be supported for developers who need to build the images by themselves)

[TheFox0x7]

How would you keep it sane though? It is a good idea (though I thought of it in inverse - take binaries from docker nvm windows builds exist). But I don't see how you'd add the binary without another Dockerfile with ADD for remote resource. That could replace the existing ones sure but then I can't exactly make my own container.
How do you see it?

[wxiaoguang]

Just an idea 😄 not sure whether it brings enough value

[TheFox0x7]

I'd say it does but inverse (binary from container) would be simpler to do (safe for windows builds). I can look at it later.

Is the git checkout in container even used btw? I don't exactly see a usecase for it...
I mean I do but I'm not sure why would someone use that instead of checking out the version with git. Maybe I'm missing something?

[wxiaoguang]

Is the git checkout in container even used btw? I don't exactly see a usecase for it... I mean I do but I'm not sure why would someone use that instead of checking out the version with git. Maybe I'm missing something?

Agree with you. That checkout came from "Docker multi-stage (#2927)", it seems no real use case for it.

• permit to chose the version of the binary build via --build-arg GITEA_VERSION=v1.2.3

If removing it can make the whole system simpler, maybe it's fine to remove it.

If removing it doesn't simplify, maybe it can still be kept for a while.

---

Update: it just conflicts the GITEA_VERSION used by Makefile:

• In Makefile, GITEA_VERSION means always set it as the version, no matter what commit it uses
• In Dockerfile, GITEA_VERSION means "checkout the target branch" .....

[wxiaoguang]

Overall LGTM.

The new approach looks pretty cool and much clearer than before.