Closed mludowise closed 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.
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.
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
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
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.
Thank you for the thorough explanation. The way you're handling versioning makes perfect sense!
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/appcastI 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...