Add support for github releases about libgrabber

[tomByrer]

Would have to use wildcards, since some like to jquery-thing-1.2.5.zip IIRC.

[coreybutler]

I too would like to see this. It feels really dirty having a distribution folder in the source code when github releases are designed for.... releases. In my use case, I do not want to pull the zip/tarball from a release, since they consist of source code. I only want to release the files explicitly produced for release. See this release for an example.

Having a dist directory in the github repo has actually caused a bunch of unnecessary challenges for my team. People will update the source but forget to build, or we'll setup a git hook to build, which winds up with a bunch of edge case errors (and requires everyone to have a git hook). To get around this, I have setup what feels like a kludgy build process. We push our source changes, which triggers a CI process. Upon success, we have the option to build a release. Once the release is built, we use a github webhook to trigger another process that copies the release files to a separate github repo that only contains the production-ready code. Then we build an npm package, primarily to trigger jsdelivr update, which now points at our "distribution repo". This feels convoluted. It would be far simpler to use Github releases to trigger the update, then just read from the release. I feel strongly enough about this that I'm willing to take a stab at creating this functionality. If someone can point me in the right direction to get started, I believe it would be a straightforward and rather quick effort.

Here's some initial code I pulled from one of my processes to illustrate the general idea that has worked for me. This code finds the latest release for a given Github repo and downloads the non-zip/tarball assets. I assume the next step would be to create a directory in the jsdelivr project directory and populate it.

const Shortbus = require('shortbus')
const request = require('request')
const output = path.join(__dirname, 'output')
const fs = require('fs')

fs.mkdirSync(output)

request.get({
  url: 'https://api.github.com/repos/' + process.env.owner + '/' + process.env.repository + '/releases/latest',
  headers: {
    'user-agent': 'Github Deployer'
  }
}, function (err, res, body) {
  body = JSON.parse(body)

  if (res.statusCode === 403) {
    console.error(body.message)
    return
  }

  let tasks = new Shortbus()

  body.assets.forEach(function (asset) {
    tasks.add('Download ' + asset.browser_download_url, function (next) {
      request.get(asset.browser_download_url)
        .on('error', function (err) {
          throw err
        })
        .pipe(fs.createWriteStream(path.join(output, path.basename(asset.browser_download_url))))
        .on('close', function () {
          console.log('Downloaded', path.basename(asset.browser_download_url))
          next()
        })
    })
  })

  tasks.on('complete', function () {
    console.log('All files downloaded... add them to the jsdelivr project folder?')
  })

  tasks.process()
})

There is one caveat here. The Github API has rate limiting (5K requests, but I forget when they reset). The initial request uses one and each downloaded file uses one. So, 5 files would mean 6 total requests against the Github API. Across all projects, I suspect that would add up quickly. Perhaps this is why it hasn't been done before?