Open
Description
Other possible features that might belong to this SBT plug-in:
- generate plug-in manifest file for network installation
- make sure the plug-in name is unique (there are already many plug-ins)
- enforce minimal common requirements for plug-ins, e.g.:
- description is present
- unique (font) icon?
- supported versions/links of dependencies (not GitBucket) if the plug-in is an integration of other software
- Document steps to publish the plug-in
Metadata
Metadata
Assignees
Labels
No labels
Activity
takezoe commentedon Dec 8, 2018
This will be provided by the GitBucket plugin build farm. Since the build farm is still in testing phase, it hosts only limited plugins currently.
I think that plugins will have to be identified by
authoer/repository
as GitHub.In my plan, the plugin build farm will build plugins for each GitBucket version automatically. Plugin developers need to only register their plugins to the build farm.
aadrian commentedon Dec 8, 2018
What about company internal plug-ins?
Wouldn't be simpler if it would be the job of a "signing/publishing" SBT task, just like in the case of Maven? The Maven POM is also genrated by the publishing task, not a Maven Build Farm.
That would guarantee uniqueness - unless some plug-ins are hosted on GitLab or alternative repos.
I see, however IMHO there still must be some sort of manual vetto-ing, since completely automating this stuff would allow malware to sneak in very easily.
takezoe commentedon Dec 9, 2018
I think that copying assembly jar is enough solution for such company internal plugins. Network installation wouldn't be necessary for them.
Yes. It would be impossible to guarantee by a sbt plugin, anyway.
As I explained, the build farm is still experimental. When it's ready to release for third parties, it will come with the exact documentation for the plugin developers.