Skip to content

Possible features for this SBT Plug-in? #3

Open
@aadrian

Description

@aadrian

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

Activity

takezoe

takezoe commented on Dec 8, 2018

@takezoe
Member
  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

aadrian commented on Dec 8, 2018

@aadrian
MemberAuthor
  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

takezoe commented on Dec 9, 2018

@takezoe
Member

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions

      Possible features for this SBT Plug-in? · Issue #3 · gitbucket/sbt-gitbucket-plugin