Avoid `dist` in master branch
Closed this issue · 9 comments
The grafana plugin infrastructure seems to promote checking in dist to the master branch. This is kinda annoying and makes many pull-requests break -- since people add the dist :(
Rather than checkin dist, we could:
- ignore it from master
- make a release script that
- adds the dist folder
- adds a tag for that version
- gives the json required to add to https://github.com/grafana/grafana-plugin-repository/blob/master/repo.json
I have a very very ugly script working here:
https://github.com/ryantxu/ajax-panel/blob/master/release.js
would be nice to get something general that could be reused across plugins :)
Yes, the dist folder is suboptimal for working with git.
One advantage it has is that people can clone this into their data/plugins dir, and the plugin just works. But it could be argued that if they installed it that way they might also have a node environment.
How would this work with the grafana-cli tooling @torkelo ?
So the way things work is that grafana-cli sends a request to grafana.com, which returns a redirect to the download url. Right now it always redirects to the github url for the auto-generated .zip of the repo at the specified commit hash, but we could extend it to support specifying an alternate .zip url, such as a release asset. I've been thinking about that a little for handling backend plugins, if grafana-cli passed the architecture in that call then it would be possible for grafana.com to return a URL to the .zip for that architecture, rather than needing to package binaries for all architectures in a single .zip file.
@DanCech, @davkal -- i don't think anything would need to change for grafana-cli to keep working exactly as it is. This is really a change to the release process on the plugin side
- .gitignore dist in master
- create a release branch
- force add the 'dist' folder in the release branch
- check it in...
- submit the commit hash for the release branch with checked in dist to https://github.com/grafana/grafana-plugin-repository/blob/master/repo.json
One advantage it has is that people can clone this into their data/plugins dir, and the plugin just works.
They could still clone the release/version branch and it would work... just not on master :)
@daniellee what do you think about this release mechanism? Would be good to have a standard.
I added the same script to the plotly plugin, and @daniellee confirmed that the branch structure works.
I have a patch for grafana.com that checks to see if there is a release named v<version>, then if that release has an asset attached to it, it returns that instead of a zipball of the referenced commit. If no matching release is found, or the release does not have an asset attached to it, then it falls through to returning the zipball of the commit.
That will work fine for folks who want to use a release branch with dist checked in, as well as anyone who would rather compile dist outside and upload a packaged .zip as a release asset.