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).

[lunny]

These files change maybe added accidentally?

[TheFox0x7]

no that's to avoid having to set permissions during build.

[wxiaoguang]

Maybe the chmod was there for Windows developers? Windows git clone doesn't have "+x" mod?

(Just a guess, correct me if I was wrong)

[TheFox0x7]

It was introduced in #27757 and I don't see any explanation so... I have no idea either.

Since CI builds on linux I'm not that concerned with potential windows issues in here, especially since this unifies the build stage (which I did not merge into a single file here because it didn't feel like much gain - I could though if you think it's worth it).
If someone with windows wants to try it and it's a problem, I'll work on a solution.

[wxiaoguang]

It is older than that, see chmod executables when copying to the docker #17423

And there were some Windows developers ("make fmt" fails on windows #14438, Some file perms are incorrect in the docker image built from Windows #17400), I don't know whether as of today whether Windows developers need to build container image, and/or whether the "chmod" need the tricks.

[silverwind]

Imho, the only supported development environment on Windows should be WSL, these other stuff are usually "git bash" etc, which are fake Linux environments and imho do not have to be supported.

[lunny]

Why we need to copy sub directories one by one? I think .dockerginore can work well.

[TheFox0x7]

I wanted to avoid copying entire .git directory, it's not possible to bind it if it's in dockerignore sadly.

[wxiaoguang]

Maybe related #35697 (comment)

But I think the shallow clone's ".git" directory won't be too large? And why it can't mount the source directory directly?

[TheFox0x7]

The mount didn't work for some reason though it should've (reason being it tried to write to read-only stuff but theoretically it should just layer on the read only items and persist to later stage) . I'll tinker with it some more as pure mount would be simplest to work with

[silverwind]

I feel like this copying belongs in the Makefile, not in this docker file. You have various variables like GO_DIRS there that should be helpful. Maybe call it make docker-copy or something.

[TheFox0x7]

I don't follow - you mean like bind the source to the container and call make docker-copy to copy it from a bind mount to a layer?
What would be the point?

[silverwind]

It's about consolidating such logic into the Makefile to have shared variables like GO_DIRS which are easier to maintain than having logic spread in multiple files where they can go out of sync.

Once you have make and Makefile available in your container, you can run make targets.

[wxiaoguang]

make frontend depends on backend code, for example: tailwind class generation.

And I am not sure why it should manually copy the directories from a long list, it seems difficult to maintain.

ps: I don't use Actions so I am not able to comment too much on other changes.

[silverwind]

Just add this to the Dockerfiles instead:

LABEL org.opencontainers.image.authors="[email protected]"

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="[email protected]"

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.