sketchpacks / feedback

Have some feedback? Leave it here.
4 stars 1 forks source link

[Question] How does Sketchpacks work with releases? #36

Closed mludowise closed 7 years ago

mludowise commented 7 years ago

This is really two questions that are related.

How is it that some plugins in the Sketchpacks API have multiple versions?

For example, I see that sketch-data-populator has 26 versions in its appcast: https://api.sketchpacks.com/v1/plugins/com.precious-forever.sketch.datapopulator2/appcast

I tried to do this with my plugin, Sketch-HTML-Export, by creating multiple releases in GitHub (0.1, 0.2) and installing Sketchpacks Relay, but I'm seeing only the latest version (0.2) in the appcast file. It's not particularly important for me to have multiple versions in my appcast file as long as the latest is there, I'd just like to understand how it works.

How do you handle Sketch plugins are built and hosted as releases?

For example, the sketch-data-populator Github repository doesn't contain a valid plugin but instead the source code for a plugin that is built using gulp. They host built versions of their plugin on their release page. Does Sketchpacks take this into account? On initial inspection, it looks like it doesn't handle this well.

Possible solution

Sketch Plugin Manager also has no way of handling plugins that are not directly hosted in their GitHub repositories, but this should be easier to do now that plugins are moving to an appcast model. I'm wondering if there's any easy way allow plugin developers to leverage GitHub releases to either...

willdavis commented 7 years ago

@mludowise there were a couple bugs contributing to this. https://github.com/sketchpacks/bug-reports/issues/33 is related to this question.

I've pushed some fixes for the versions_count counter which was also effecting the appcast versions. You should see all releases as versions in the appcast XML. If the plugin does not use releases, then only one version will be in the appcast, the HEAD version.

Here's a little more info about how Sketchpacks handles releases.

Supported Versioning Options

If the repository has releases, those will be used instead of commits. And if the repository has release assets, those will be used instead of the release archive.

Commits

Changes to the repositories default branch will update the plugins HEAD commit SHA in the registry. When the version in the manifest.json is updated, the HEAD commit SHA will be used for the download endpoint.

Any commit can be downloaded using the ?version= param and giving it a full commit SHA. For example:

https://api.sketchpacks.com/v1/plugins/com.mludowise.htmlexport/download?version=fb1ee51a5bff7e150373a58650481ec3d1a025ae

This versioning option is only available to public repositories, because only the source code can be served for the download.

Under the hood, we are using the Github codeload endpoint:

https://codeload.github.com/mludowise/Sketch-HTML-Export/legacy.zip/fb1ee51a5bff7e150373a58650481ec3d1a025ae

Releases

If the release has uploaded assets, the first .zip asset will be used for the version. If no assets are present, then the zipped archive will be used for the version.

private repositories MUST use zipped release assets, the archive download will serve the source code.

Under the hood, we are using the asset download url, or release archive url.

Archive download url:

https://github.com/mludowise/Sketch-HTML-Export/archive/0.2.zip

Asset download url:

https://github.com/adamkirkwood/sketch-timestamper/releases/download/v1.0.1/timestamper.sketchplugin.zip

Build process

We do not have any plans to support a CI build process within Sketchpacks.

However, plugin developers can use tools such as SKPM to build plugin bundles and upload them to Github as a release asset.

Sketchpacks Relay or the background cron job can then pick up the assets and update the registry accordingly.

mludowise commented 7 years ago

Thank you for the thorough explanation. The way you're handling versioning makes perfect sense!