Open fekle opened 3 months ago
Please try docker build -t GITEA_HOST/test/test:test . --provenance=false
, then push.
Based on my research this could have to do with build provenance aka https://docs.docker.com/build/attestations/slsa-provenance/.
My docker setup is old and has no containerd image store, therefore is my system probably unaffected as I can push. For me this seems to be turned off by default due to that reason and trying to enable it tells me that my setup cannot attest.
docker build -t GITEA_HOST/test/test:test . --attest type=provenance,mode=max
ERROR: Attestation is not supported for the docker driver.
Switch to a different driver, or turn on the containerd image store, and try again.
Learn more at https://docs.docker.com/go/attestations/
I would try to debug this next week with provenance enabled for a dind container or similar.
maybe I'm on a wrong path here.
Thanks for your swift reply!
I just tried building and pushing without provenance, that seems to work, with plain docker at least - thanks! Pushing with Buildkit via earthly unfortunately still fails, see below.
> docker build --provenance=false -t GITEA_HOST/test/test:test-without-provenance .
[+] Building 0.5s (5/5) FINISHED
=> [internal] load build definition from Dockerfile
[...]
=> => unpacking to GITEA_HOST/test/test:test-without-provenance
> docker push GITEA_HOST/test/test:test-without-provenance
The push refers to repository [GITEA_HOST/test/test]
7b24851aa36d: Layer already exists
test-without-provenance: digest: sha256:[...] size: 503
(fun fact: at first the
size: 503
confused me, thinking that now i'm getting an error 503 ...)
Gitea log:
2024/08/18 14:35:13 ...eb/routing/logger.go:102:func1() [I] router: completed HEAD /v2/test/test/blobs/sha256:[...] for REDCACTED:0, 401 Unauthorized in 0.1ms @ container/container.go:126(container.ReqContainerAccess)
2024/08/18 14:35:13 ...eb/routing/logger.go:102:func1() [I] router: completed HEAD /v2/test/test/blobs/sha256:[...] for REDCACTED:0, 401 Unauthorized in 0.0ms @ container/container.go:126(container.ReqContainerAccess)
2024/08/18 14:35:13 ...eb/routing/logger.go:102:func1() [I] router: completed POST /v2/token for REDCACTED:0, 404 Not Found in 0.0ms @ container/container.go:172(container.AuthenticateNotImplemented)
2024/08/18 14:35:13 ...eb/routing/logger.go:102:func1() [I] router: completed GET /v2/token?scope=%2A&scope=repository%3Atest%2Ftest%3Apull%2Cpush&service=container_registry for REDCACTED:0, 200 OK in 57.1ms @ container/container.go:149(container.Authenticate)
2024/08/18 14:35:13 ...eb/routing/logger.go:102:func1() [I] router: completed HEAD /v2/test/test/blobs/sha256:[...] for REDCACTED:0, 200 OK in 1.3ms @ container/container.go:486(container.HeadBlob)
2024/08/18 14:35:13 ...eb/routing/logger.go:102:func1() [I] router: completed HEAD /v2/test/test/blobs/sha256:[...] for REDCACTED:0, 200 OK in 1.2ms @ container/container.go:486(container.HeadBlob)
2024/08/18 14:35:13 ...eb/routing/logger.go:102:func1() [I] router: completed HEAD /v2/test/test/manifests/test-without-provenance for REDCACTED:0, 404 Not Found in 0.5ms @ container/container.go:624(container.HeadManifest)
2024/08/18 14:35:13 ...eb/routing/logger.go:102:func1() [I] router: completed PUT /v2/test/test/manifests/test-without-provenance for REDCACTED:0, 201 Created in 3.6ms @ container/container.go:539(container.UploadManifest)
Note that the first HEAD
requests still results in 401, do you know what's up with that?
That's also what is now breaking my BuildKit/Earthly build:
unexpected status from HEAD request to https://GITEA_HOST/v2/test/test/blobs/sha256:[...]: 401 Unauthorized
Also, there is still a 404 error for that manifest endpoint, but the docker client is not complaining anymore - strange.
Please let me know if i can be of any help with debugging this issue further :)
I had a look at where the 401 is coming from, container/container.go:126
; thats:
if ctx.Doer == nil || (setting.Service.RequireSignInView && ctx.Doer.IsGhost()) {
apiUnauthorizedError(ctx)
}
As a quick test, i set REQUIRE_SIGNIN_VIEW
to false
in my app.ini
, restarted Gitea and retried, but i'm still getting the same error with Buildkit - so that's not it. Given that this issue seems to come from ctx.Doer == nil
and occurs at the HEAD
request, maybe Buildkit is not sending any credentials with that particular request?
what is now breaking my BuildKit/Earthly build
Are those still have provenance on? I mean it's not unlikely that provenance is not supported yet by the Gitea Container Registry.
See https://docs.docker.com/build/building/variables/#buildx_no_default_attestations for an env variable.
Also, there is still a 404 error for that manifest endpoint, but the docker client is not complaining anymore - strange.
Pure logical, isn't the 404 here just telling docker that the tag doesn't exist yet Then docker creates the tag with PUT that returns created. Now I would expect doing this a second time wouldn't result in a 404 before the put
BTW yes I used buildkit to push my image yesterday, no error (what I tested is in discord, between your post and your reply to me)
Ok I'm out, as I cannot reproduce the issue on my system, provenance push didn't fail for me.
I have created an dind container with containerd image cache and it doesn't fail.
The flag REQUIRE_SIGNIN_VIEW isn't enabled for me, because my ports are not exposed to the www and my reverse proxy configuration is probably totally different.
Maybe someone else can have a look
Are those still have provenance on? I mean it's not unlikely that provenance is not supported yet by the Gitea Container Registry.
Yes, i used BUILDX_NO_DEFAULT_ATTESTATIONS=1
but could well be that buildkit itself is not picking up that argument, as i'm using a buildkit in my CI; I will have to debug this further. Kinda annoying that BuildKit does not handle this gracefully and just assumes that the registry supports this feature.
But the 401 in my log output above is from a normal
docker push with the --provenance=false
command, which seems to ignore the 401 when BuildKit doesn't. Given that there provenance is disabled for sure, that seems to be a different issue.
Pure logical, isn't the 404 here just telling docker that the tag doesn't exist yet Then docker creates the tag with PUT that returns created. Now I would expect doing this a second time wouldn't result in a 404 before the put
While that would indeed make sense, I don't think that's the case as that still occurs when the image and all layers already exist, and the error in the logs is container.AuthenticateNotImplemented
. Not sure what that is about, but it could be related to the 401s before.
Ok I'm out, as I cannot reproduce the issue on my system, provenance push didn't fail for me.
I have created an dind container with containerd image cache and it doesn't fail.
The flag REQUIRE_SIGNIN_VIEW isn't enabled for me, because my ports are not exposed to the www and my reverse proxy configuration is probably totally different.
Maybe someone else can have a look
That's interesting that it doesnt fail for you, so maybe it's something with my configuration. But thank you for your help!
Allright, I got pushing in Actions to work.
I was using
- name: login to container registry
uses: docker/login-action@v2
with:
registry: GITEA_HOST
username: ${{ gitea.actor }}
password: ${{ gitea.token }}
to log in to the container registry.
While the login succeeds, pushes fail. When I create a personal access token with access to packages and then use my username as username
as well as that token as password
, I can push.
Now, if I want to keep that more secure, I can put that token into a secret - however, given that I can only define secrets per repository and not globally, I'll have to copy that secret definition to every repository that I'm using CI with.
Is there a better way to do this? Researching on Google and so on leads to scattered forum posts from various versions, so I can't seem to find a definitive answer. Coming from GitLab CI, there were 3 auto-generated variables in CI: CI_REGISTRY
, CI_REGISTRY_USER
, and CI_REGISTRY_PASSWORD
. That made pushing to the built-in registry a breeze; it would be nice if Gitea had something similar - I would think that pushing to the built-in registry is a common action in CI.
I'd be happy to write some documentation on that and open a PR once I know the "idiomatic" way to do all of this :)
@fekle In my case, the organisation is "oi" and project is "test". It's a similar use-case like you, where I am trying to use gitea as container registry along with git repo. In my scenario, I've deployed gitea locally and somehow it's failing.
% docker build -t 127.0.0.1:3000/oi/test . [+] Building 2.1s (5/5) FINISHED docker:desktop-linux => [internal] load build definition from Dockerfile 0.0s => => transferring dockerfile: 61B 0.0s => [internal] load metadata for docker.io/library/debian:12 2.0s => [internal] load .dockerignore 0.0s => => transferring context: 2B 0.0s => CACHED [1/1] FROM docker.io/library/debian:12@sha256:b8084b1a576c5504a031936e1132574f4ce1d6cc7130bbcc25a28f074539ae6b 0.0s => exporting to image 0.0s => => exporting layers 0.0s => => writing image sha256:0c21f32bd1037ae97c3535bb9c7f15f7ca0f829e5809161f607531c20764b61e 0.0s => => naming to 127.0.0.1:3000/oi/test 0.0s
% docker push 127.0.0.1:3000/oi/test:test The push refers to repository [127.0.0.1:3000/oi/test] Get "http://127.0.0.1:3000/v2/": dial tcp 127.0.0.1:3000: connect: connection refused
telnet and netcat is working:
nc -zv 127.0.0.1 3000 Connection to 127.0.0.1 port 3000 [tcp/hbci] succeeded!
telnet 127.0.0.1 3000 Trying 127.0.0.1... Connected to localhost.
Exact same issue here. Running the latest official Gitea image via docker. The main git functionality has been working fine for months. The comments above seem to suggest creating a PAT can work, but that didn't do it for me. I created a new PAT, and tried a docker push
. The PAT was used according to the Gitea UI, but still the same output as others see.
Then tried a docker build --provenance=false
image build, which pushed fine.
I had expected this to work somewhat more 'out of the box' as a basic push doesn't seem special.
For reference, output of the failed push below. Again: with --provenance=false
worked fine. Replaced strings with descriptions for privacy.
$ docker --version
Docker version 27.3.1, build ce12230
$ docker push [host]/[organization]/[repo]/[image-name]:latest
The push refers to repository [[host]/[organization]/[repo]/[image-name]]
73b263454379: Pushed
d88d75d6bbae: Layer already exists
a480a496ba95: Layer already exists
a5072a025aa2: Layer already exists
ae8522101371: Layer already exists
88900f0244bb: Layer already exists
5cfa0738ac2f: Layer already exists
2f779fda9095: Layer already exists
24f2c78e0691: Layer already exists
failed commit on ref "index-sha256:07761bba483df9b7123227be97a913b01bb62bee3533214537d694ec3902ec08": unexpected status from PUT request to https://[host]/v2/[organization]/[repo]/[image-name]/manifests/latest: 404 Not Found
What's your PAT scope?
Good point - (non public) packages read & write, I failed to consider a wider scope but on the flip side thinking about it now I would expect that to be enough.
Op do 24 okt 2024 om 00:18 schreef Lunny Xiao @.***>
What's your PAT scope?
— Reply to this email directly, view it on GitHub https://github.com/go-gitea/gitea/issues/31861#issuecomment-2433570979, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA6CPHKPBZT6ZYDUTJ4F5L3Z5AOBZAVCNFSM6AAAAABMWJQFWWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMZTGU3TAOJXHE . You are receiving this because you commented.Message ID: @.***>
I'm having a similar issue with podman push. As far as I know, there is no equivalent for --provenance=false
. Podman version is 5.2.5 and gitea is 1.22.3 (via docker hub):
Getting image source signatures
Copying blob 49cadc25f7bb [--------------------------------------] 8.0b / 1.4MiB | 1.9 MiB/s
Copying blob edeb1fd6bf66 [--------------------------------------] 8.0b / 4.1MiB | 1.7 MiB/s
Copying blob 8cbe4b54fa88 [--------------------------------------] 8.0b / 80.1MiB | 1.1 MiB/s
Copying blob fa3e1fa14e04 [--------------------------------------] 8.0b / 341.5KiB | 2.4 MiB/s
Copying blob 7ddf8331309f [--------------------------------------] 8.0b / 3.5KiB | 4.0 MiB/s
Copying blob dcd40c14ad70 [--------------------------------------] 8.0b / 9.1MiB | 1.1 MiB/s
Copying blob 9b03e049cc12 [--------------------------------------] 8.0b / 157.3MiB | 1.2 MiB/s
Error: writing blob: initiating layer upload to /v2/[USERNAME]/blobs/uploads/ in [HOST]:[PORT]: StatusCode: 404, ""
My version is Gitea v1.22.3, previously I used Docker build - t text: latest .
Directly building an AMD64 image can successfully push it up.
But after enabling multi platform build, Docker buildx build -- platform Linux/amd64, Linux/arm64- t test: latest .
, the image layer can be uploaded, but the final step is also
failed commit on ref "index-sha256:8a4a910b69...": unexpected status from PUT request to http://192.168.1.6:8080/v2/my/test/manifests/latest: 404 Not Found
Description
Hi there!
I'm in the process of migrating from GitLab to Gitea, and so far I'm very happy with Gitea - migration was smooth, and things like Actions work great!
Now I wanted to also use Gitea as my Docker Registry to host my container images, but I'm stuck there. Pushing image layers works fine, but the final manifest push fails with 404. I think this issue is related to existing issues such as #31802 and #31644, but I didn't want to spam those issues.
First of all - to make sure that this is not related to my migrated groups and repositories - I created a new Organization called "test" and a project called "test" in my Gitea instance. I also enabled debug logging.
Then, when I'm trying to push a minimal image from my computer, I get this:
The same thing happens with an Actions workflow and BuildKit.
On the Gitea server side, here are the startup logs:
And this is the output when pushing aforementioned image:
Strangely, I'm seeing
401 Unauthorized
errors there; which I'm not seeing in the Docker client. I am logged into the registry viadocker login
with my administrator user. I also tried creating a new user, which I added to the aforementionedtest
group, but the same issue persisted. I also made sure that things like filesystem permissions as well as the reverse proxy configuration are correct.For some context, here Is my
app.ini
The reverse proxy configuration:
And the
docker compose
config for Gitea:I'm kind of at a loss here and would be very grateful if anyone could point me in the right direction :-)
Gitea Version
1.22.1
Can you reproduce the bug on the Gitea demo site?
No
Log Gist
No response
Screenshots
No response
Git Version
2.45.2
Operating System
Docker image:
gitea/gitea:1
; Host:Debian 12.6 6.1.0-23-cloud-amd64
How are you running Gitea?
Hosting myself, on
Docker 27.0.3
behindCaddy v2.8.4
.Database
SQLite