-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add Package Registry #16510
Add Package Registry #16510
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Skimmed through it, what I've seen seems pretty good.
My focus was on Maven as that's what I'm most comfortable with.
No doubt, there will be reviewers that actually read through all 5000 lines of code… 😉
URL string `xml:"url"` | ||
Distribution string `xml:"distribution"` | ||
} `xml:"licenses>license"` | ||
Dependencies []struct { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not sure whether they are needed, but the Maven Language Server gives me a few more options to pass for each dependency.
They are:
- optional (String)
- type (String)
- exclusions (a set of dependencies)
- classifier (String)
But I totally understand it if you want that to be part of another PR, the basic functionality already stands.
It wouldn't surprise me, however, if the current implementation fails as soon as one of the advanced features is used, limiting the initial usability. The same is true for the missing fields mentioned below.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm no Maven expert but does the client really trust the server informations about the dependencies? I would expect the client downloads the package and checks the local pom
file for all needed informations.
Edit: The client downloads the .pom
asset with all original informations so all metadata is just used for the UI. I don't know if these are benefitical for a normal user.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As I already said, I am also unsure whether they are needed.
Potentially yes, potentially no.
It could, however, be that the package cannot be registered in case advanced properties are used in the pom file. That's what I'm uncertain about.
In the worst case, this will simply have to be added to the data model in another PR, after this PR has been merged and tested thoroughly.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The pom
file is not generated but the original file is stored. So all metadata is only used for the Gitea UI. Currently I don't think there is a problem.
Version string `json:"version"` | ||
} | ||
|
||
type pomStruct struct { |
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
Since docker is also some kind of package, maybe we should consider what's relation between this one and #14919 . @a1012112796 |
Thanks for the fantastic PR! Two small things you can consider to add in this PR. One is add webhooks for packages, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Holy, I think I've never been sitting so long on a single review as I have now.
About four hours, and I reviewed only the easy 60%...
But before I forget the rest or this PR gets merged, here are a few points I noticed.
RegisterTaskFatal("cleanup_packages", &OlderThanConfig{ | ||
BaseConfig: BaseConfig{ | ||
Enabled: true, | ||
RunAtStart: true, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wasn't there a setting for this? Is that (now) unused?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are you talking about #19221? If yes, that's already changed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, that value is simply the default value if the setting is missing, correct?
In that case ignore my comment, I thought it would mean that it would always run at start.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Minimal docs typos
Beside the implemented providers it could also make sense to implement the Terraform registry api, Terraform module api and the Terraform remote state api. |
Good idea but let's merge it at first and send other PRs. |
Last call for reviews. If no code change in one day, let's merge. |
Co-authored-by: Thomas Boerger <thomas@webhippie.de>
@wxiaoguang hopefully my comments will be fixed before the merge ;) |
Yup, these document fixes have been committed. Anything more to change? |
Not from my side, looks good. Even if I'm still against bloating the gitea core more and more with features, but this won't change without a plugin system. |
Agree to be more careful about minority features that bloating the core code. Gitea should only introduce features which benefit most users. Personally speaking, I am not optimistic about Gitea can have a plugin system in near future. Many simple and refactoring PRs just get delayed for long time, even months, I can not imagine how the plugin system could be done in a predictable future. And indeed it seems that a plugin system is not a high priority task at the moment. |
Let's merge then send patches. It took so long for this PR. |
One day comes a little early 😂 but it's not bad, I like it. Let's move on ~~~~~ 🎉 test and patch |
* giteaoffical/main: (31 commits) Add Package Registry (go-gitea#16510) Show messages for users if the ROOT_URL is wrong, show JavaScript errors (go-gitea#18971) [skip ci] Updated translations via Crowdin Make git.OpenRepository accept Context (go-gitea#19260) Use full output of git show-ref --tags to get tags for PushUpdateAddTag (go-gitea#19235) When conflicts have been previously detected ensure that they can be resolved (go-gitea#19247) More commit info from API (go-gitea#19252) Move some issue methods as functions (go-gitea#19255) Move project files into models/project sub package (go-gitea#17704) Granular webhook events in editHook (go-gitea#19251) Provide configuration to allow camo-media proxying (go-gitea#12802) Move init repository related functions to modules (go-gitea#19159) Move organization related structs into sub package (go-gitea#18518) Refactor repo clone button and repo clone links, fix JS error on empty repo page (go-gitea#19208) Show last cron messages on monitor page (go-gitea#19223) Allow API to create file on empty repo (go-gitea#19224) Use goproxy.io instead of goproxy.cn (go-gitea#19242) New cron task: delete old system notices (go-gitea#19219) Let web and API routes have different auth methods group (go-gitea#19168) Only send webhook events to active system webhooks and only deliver to active hooks (go-gitea#19234) ...
A little bit rushed at the end but I'm happy it got merged after that long time working on it. |
locked as new issues should be created & linked to this ... if something pops up |
This PR adds support for multiple package registries.
Currently implemented are
Every user/org has an own package registry for all different types of packages.
Screenshots
Package list:
Admin page:
Composer package:
Conan package:
Docker image:
Helm Chart:
Generic package:
NuGet:
npm:
Maven:
PyPI:
RubyGems:
Instructions for testing: #16510 (comment)
close #15706
close #2316