gitea
gitea copied to clipboard
Add uploading packages through the Web UI
At the Moment you can upload Packages only through the API. So if you want to e.g. upload a Debian package that you have build, you need to lookup the command and maybe you also need to create a Token. This PR adds a easier way: Now you can upload packages through the Web UI with just a few clicks! This will of course not work with all package types. You can't expect to upload e.g. a Container Image this way. This PR aims at those Packages types, than can be uploaded using curl.
Currently supported types:
- Alpine
- Debian
- Generic
- RPM
To-do:
- Support more types
- Improve UI
- Make UI translatable
- Find bugs
Screenshots:
cc @KN4CK3R
- Filename seems to conflict with uploaded file. Do we require a certain naming pattern?
- The file input should look like the text inputs, e.g. label before, a break and same width as the other inputs
Filename seems to conflict with uploaded file. Do we require a certain naming pattern?
The Filename is only used by generic Packages. It's the filename under which the package is published later. I though it was a good idea to add this instead of using the name from the uploaded file, so nobody ends up with something like package_test4.zip. Maybe it would be a good idea to use something like "(leave empty to use the file name from the uploaded file)" for this field.
The file input should look like the text inputs, e.g. label before, a break and same width as the other inputs
I will do that.
What do those package filenames look like? I assume they are different per type of package? Maybe we can keep things simple and just auto-generate a filename from name and version only?
Oh and the input placeholders in UI should show sample values, e.g. 1.2.3 for version for example.
What do those package filenames look like?
Hallo.txt is the filename in this case.
I assume they are different per type of package?
No. As I said, they only exists for generic packages.
Maybe we can keep things simple and just auto-generate a filename from name and version only?
That sounds more complex and not simpler. The Version filed exists (as far as I know) also only for generic packages. For other Formats, the Version is extracted from the package itself.
Oh and the input placeholders in UI should show sample values, e.g.
1.2.3for version for example.
You can use whatever you want as version. There is no need to use somtehing like 1.0. You can also use MyCoolNewVersion as version.
Here are Screenshots how it currently looks:
I assume they are different per type of package?
No. As I said, they only exists for generic packages.
Just to note, there is filename related logic in other package types too (Conan, Maven, NuGet, ...)
Just to note, there is filename related logic in other package types too
Thanks. I will see that when I add those types. But for this PR, I think it's better to focus on those packages that can be uploaded with a simple PUT request.
I also added support for RPM packages now.
UI looks good, but I would replace "The Package:" with "File:"
I had moved to upload code now to the specific service of each package rather than bundling all in one upload service
I have now added support for Alpine Packages. I also consider this PR now as ready. There are package types missing, but they can be added in a later PR, as I don't want to grow his PR too big. I think those 4 package types are a good start.
Is it ready for review?
Yes, it is ready to review
Can you add some unit test cases, if applicable?
Can you add some unit test cases, if applicable?
I don't know how to do this. We don't have something like Selenium to write real frontend tests (I think this should be introduced). The only thing I could do is making a POST request to the form endpoints. But everything I found in the Gitea test suite that does this for the frontend (Search for GetCSRF) uses only strings. But we have a multipart form with file uplo0ad here. Testing this would most likely require some changes in the test suite. Luckily the package upload code itself is already tested. So the only backend files that are not tested are those in routers/web.
no worries
with playwright we can achieve that
Its looks like playwright is not really used besides some examples
@JakobDev
I have function that might help to automatically get a response code in PR, it it is not finished, i am not sure about response codes.
// Automatically get HTTP status from error.
func StatusFromError(err error) int {
switch {
case errors.Is(err, ErrNotExist):
return http.StatusNotFound
case errors.Is(err, ErrAlreadyExist) || errors.Is(err, ErrLimitExceeded):
return http.StatusConflict
case errors.Is(err, ErrPayloadTooLarge):
return http.StatusRequestEntityTooLarge
case errors.Is(err, ErrInvalidArgument) || errors.Is(err, io.EOF):
return http.StatusBadRequest
case errors.Is(err, ErrPermissionDenied):
return http.StatusForbidden
}
return http.StatusInternalServerError
}
It might be possible to use this function to check, upload error is caused by user, and which type is it. Should be possible not to return IsUserError value and not to make manual response code assignment (response code can be used to check, if error is caused by user, if reponse code is not InternalServerError).
Any new update on this @JakobDev ?
@JakobDev would really love to see this feature merged ... been a year since it got any love though :(
I can see there are interests on this feature.
But this PR is stale for long time and it doesn't seem to get updates (the CI hadn't passed yet ....), same situation to other PRs like: https://github.com/go-gitea/gitea/pull/27772#issuecomment-2183687648
Quote to here:
Actually usually I also tried to help & push some PRs to move on. The problem is that many PRs are inactive and not that responsive, for example,
25049since Jun, 2023. (not a native speaker, I would like to mean "have responses after getting review comments" byresponsive). So usually I would like to spend time on PRs (authors) that are more active. ps: there are still some problems in this PR I guess .......
Still, I can see some problems (especially design/architecture problems) in this PR which need to fix. Maybe it needs some time to make it mature.
Perhaps there is no need to modify the backend code; we can simply use JavaScript for asynchronous uploads on the frontend.