Skip to content
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

Possible features for this SBT Plug-in? #3

Open
aadrian opened this issue Dec 8, 2018 · 3 comments
Open

Possible features for this SBT Plug-in? #3

aadrian opened this issue Dec 8, 2018 · 3 comments

Comments

@aadrian
Copy link
Member

aadrian commented Dec 8, 2018

Other possible features that might belong to this SBT plug-in:

  1. generate plug-in manifest file for network installation
  2. make sure the plug-in name is unique (there are already many plug-ins)
  3. enforce minimal common requirements for plug-ins, e.g.:
    1. description is present
    2. unique (font) icon?
    3. supported versions/links of dependencies (not GitBucket) if the plug-in is an integration of other software
  4. Document steps to publish the plug-in
@takezoe
Copy link
Member

takezoe commented Dec 8, 2018

  1. generate plug-in manifest file for network installation

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.

  1. make sure the plug-in name is unique (there are already many plug-ins)

I think that plugins will have to be identified by authoer/repository as GitHub.

  1. Document steps to publish the plug-in

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
Copy link
Member Author

aadrian commented Dec 8, 2018

  1. generate plug-in manifest file for network installation

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.

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.

  1. make sure the plug-in name is unique (there are already many plug-ins)

I think that plugins will have to be identified by authoer/repository as GitHub.

That would guarantee uniqueness - unless some plug-ins are hosted on GitLab or alternative repos.

  1. Document steps to publish the plug-in

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.

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
Copy link
Member

takezoe commented Dec 9, 2018

What about company internal plug-ins?

I think that copying assembly jar is enough solution for such company internal plugins. Network installation wouldn't be necessary for them.

That would guarantee uniqueness - unless some plug-ins are hosted on GitLab or alternative repos.

Yes. It would be impossible to guarantee by a sbt plugin, anyway.

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.

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

2 participants