-
-
Notifications
You must be signed in to change notification settings - Fork 5.7k
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
Package registry: add description from UI #20628
base: main
Are you sure you want to change the base?
Conversation
Some package types already contain a readme. (Pub (#20560), npm, PyPI) All package types (except generic) have at minimum a description field which can be provided by the package. For your Docker case you can set the description with And keep in mind the readme may change from version to version. So it may be wrong to have the readme at the package level. |
The built-in package description is mainly interesting when you use the package search system. The proposed description is supposed to describe the package inside gitea. |
Could there be a conclusion from maintainers: go or no-go? |
Feature-wise I think it's good |
@KN4CK3R has your concern been addressed? |
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.
Thanks for this PR! A few notes in terms of the code, although of course pending @KN4CK3R's feedback too.
@@ -130,6 +130,8 @@ type Package struct { | |||
Name string `xorm:"NOT NULL"` | |||
LowerName string `xorm:"UNIQUE(s) INDEX NOT NULL"` | |||
SemverCompatible bool `xorm:"NOT NULL DEFAULT false"` | |||
Description string `xorm:"VARCHAR(255)"` | |||
Readme string `xorm:"LONGBLOB"` |
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 believe TEXT is more suitable for this column, as xorm should translate it into the appropriate type for each database
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.
LONGTEXT
(for MySQL)
@@ -0,0 +1,31 @@ | |||
import $ from 'jquery'; |
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.
Linting rules should prevent the addition of new jQuery code, could you utilize vanilla JS instead?
Cc: @silverwind who has more insight into linting
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.
There is no linting for it, I don't think it's possible for the linter to distinguish old and new code. But yes, new code should prefer not to use jQuery, we want to eventually remove it.
@@ -0,0 +1,18 @@ | |||
// Copyright 2022 The Gitea Authors. All rights reserved. |
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.
Could you move this migration into a versioned directory?
Also, could you update the copyright heading to match the new format?
settings.descriptions.success = Les descriptifs ont été mises à jour | ||
settings.descriptions.error = Échec de la mise à jour des descriptifs | ||
settings.descriptions = Descriptifs | ||
settings.description.description = Description | ||
settings.readme.description = Readme | ||
settings.descriptions.button = Mettre à jour les descriptifs | ||
readme = Readme |
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.
Will be overridden by the CI again
@@ -130,6 +130,8 @@ type Package struct { | |||
Name string `xorm:"NOT NULL"` | |||
LowerName string `xorm:"UNIQUE(s) INDEX NOT NULL"` | |||
SemverCompatible bool `xorm:"NOT NULL DEFAULT false"` | |||
Description string `xorm:"VARCHAR(255)"` | |||
Readme string `xorm:"LONGBLOB"` |
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.
Why not LONGTEXT
?
@@ -414,7 +414,7 @@ var migrations = []Migration{ | |||
// v222 -> v223 | |||
NewMigration("Drop old CredentialID column", v1_17.DropOldCredentialIDColumn), | |||
// v223 -> v224 | |||
NewMigration("Rename CredentialIDBytes column to CredentialID", v1_17.RenameCredentialIDBytes), | |||
NewMigration("Rename CredentialIDBytes column to CredentialID", renameCredentialIDBytes), |
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.
This file is absolutely outdated by now as @techknowlogick mentioned in https://github.com/go-gitea/gitea/pull/20628/files#r1194390383
@@ -22,6 +22,8 @@ | |||
</div> | |||
</div> | |||
|
|||
{{template "package/content/readme" .}} |
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.
A few more registries have been merged in the mean time.
Those should get this call too.
const $tabMenu = $form.find('.tabular.menu'); | ||
$tabMenu.find('.item').tab(); | ||
$tabMenu.find(`.item[data-tab="${$tabMenu.data('preview')}"]`).on('click', function () { |
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.
This selector looks really fragile.
Please create a specific class instead and query for that class.
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.
That's just the old code, after the "editor" refactoring, no such code is needed.
Actually, this PR has been stale for too long time, I guess the author might have lost interest on it?
If it is still stale and inactive, it needs the maintainers who have writer permission to help.
I'm still not sure if we should have the readme part because some packages already provide a readme and then there would be two readmes shown. We could store the provided readme in the new readme field, but the provided readme may be version dependend. I don't know if thats really a problem. It may be needed to set/update the readme and description fields from the package metadata (which may again be version dependend). Github simply shows the |
Then maybe it (this PR's proposal) needs some real cases for why a separate (non-package) README is needed, to see whether the separate README would be widely used and really needed. |
Maybe it's like repository which has both description and README.md? |
As I said the built-in package description is mainly interesting when you use the package search system. The proposed description is supposed to describe the package inside gitea. |
Co-authored-by: delvh <dev.lh@web.de>
Co-authored-by: delvh <dev.lh@web.de>
Would it make sense to consider using the OCI annotation for docmentation -- org.opencontainers.image.documentation then it could be condition (display if the field is provided, don't if it is not) ref: https://github.com/opencontainers/image-spec/blob/main/annotations.md |
This PR fix #20604
description
andreadme