Pushing docker image appears in organization packages, but not in sub project packages #11307

New Issue

2025-11-02T09:33:58-06:00

GiteaMirror commented

2025-11-02 09:33:58 -06:00

Originally created by @christhomas on GitHub (Jul 22, 2023).

Description

When I push a package to a project in an organization, it'll appear in the organization > packages level, but not in the organization > repository > packages level.

Is this a bug or is there a step in the process I'm missing.

However. I've just found this: https://docs.gitea.com/next/usage/packages/overview#repository-packages

This is broken and unexpected behaviour. If I push to the container repository for a project, I expect it to be in the project. Not in some higher level where I have to manually link them together. If the name of the level below the organization maps to a project name, then I automatically expect the package to be in that repo > packages.

If the container I pushed doesn't map to a project, then sure, it can live at the higher organizational level.

Gitea Version

1.19.3

Can you reproduce the bug on the Gitea demo site?

Yes

Log Gist

No response

Screenshots

No response

Git Version

No response

Operating System

No response

How are you running Gitea?

On a kubernetes cluster

Database

None

Originally created by @christhomas on GitHub (Jul 22, 2023). ### Description When I push a package to a project in an organization, it'll appear in the organization > packages level, but not in the organization > repository > packages level. Is this a bug or is there a step in the process I'm missing. However. I've just found this: https://docs.gitea.com/next/usage/packages/overview#repository-packages This is broken and unexpected behaviour. If I push to the container repository for a project, I expect it to be in the project. Not in some higher level where I have to manually link them together. If the name of the level below the organization maps to a project name, then I automatically expect the package to be in that repo > packages. If the container I pushed doesn't map to a project, then sure, it can live at the higher organizational level. ### Gitea Version 1.19.3 ### Can you reproduce the bug on the Gitea demo site? Yes ### Log Gist _No response_ ### Screenshots _No response_ ### Git Version _No response_ ### Operating System _No response_ ### How are you running Gitea? On a kubernetes cluster ### Database None

GiteaMirror added the topic/packages type/enhancement labels 2025-11-02 09:33:58 -06:00

GiteaMirror commented

2025-11-02 09:33:59 -06:00

@lafriks commented on GitHub (Jul 22, 2023):

Related to #19270 task

@lafriks commented on GitHub (Jul 22, 2023): Related to #19270 task

GiteaMirror commented

2025-11-02 09:33:59 -06:00

@KN4CK3R commented on GitHub (Jul 23, 2023):

When I push a package to a project in an organization

There is no way to push a package to a repository (if project should be a repository) only to an owner. Auto-setting a repository link will be implemented in future.

@KN4CK3R commented on GitHub (Jul 23, 2023): > When I push a package to a project in an organization There is no way to push a package to a repository (if project should be a repository) only to an owner. Auto-setting a repository link will be implemented in future.

GiteaMirror commented

2025-11-02 09:33:59 -06:00

@christhomas commented on GitHub (Jul 23, 2023):

Thinking about this a little more, I can see why you might want to use your gitea packages as a way to store packages you depend on which aren't related to any project. An out of "project" or "tree" package that you want to cache in your own repo so you don't hit some rate like, for example, I can use gitea packages as a local cache for dockerhub, so I won't ever hit that rate limit they installed a while back.

That would be a useful "non-project" package that I would like to make available.

But I think the default behaviour should be, if I push a package with the name "coolcompany/someproject/restapi:latest" and I have an organization called "coolcompany" and a project inside it called "someproject", the package can be available in the organization level, but should automatically be available inside the project packages as well.

I think thats the default expectation here, right? I think from reading your todo, you're also pushing in that direction.

But I do like the fact that I can push any package name and it won't reject it, so this means I can perhaps use my gitea as a cache for dockerhub. Which is nice.

@christhomas commented on GitHub (Jul 23, 2023): Thinking about this a little more, I can see why you might want to use your gitea packages as a way to store packages you depend on which aren't related to any project. An out of "project" or "tree" package that you want to cache in your own repo so you don't hit some rate like, for example, I can use gitea packages as a local cache for dockerhub, so I won't ever hit that rate limit they installed a while back. That would be a useful "non-project" package that I would like to make available. But I think the default behaviour should be, if I push a package with the name "coolcompany/someproject/restapi:latest" and I have an organization called "coolcompany" and a project inside it called "someproject", the package can be available in the organization level, but should automatically be available inside the project packages as well. I think thats the default expectation here, right? I think from reading your todo, you're also pushing in that direction. But I do like the fact that I can push any package name and it won't reject it, so this means I can perhaps use my gitea as a cache for dockerhub. Which is nice.

GiteaMirror commented

2025-11-02 09:33:59 -06:00

@xlazom00 commented on GitHub (Jun 10, 2025):

Any plan to implement this?
When I build docker image from my repository as part of CI.
I want to see docker image in repository packages.
This is like expected behavior for me.

@xlazom00 commented on GitHub (Jun 10, 2025): Any plan to implement this? When I build docker image from my repository as part of CI. I want to see docker image in repository packages. This is like expected behavior for me.

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#11307