data-repository-service-schemas icon indicating copy to clipboard operation
data-repository-service-schemas copied to clipboard

Binaries present in gh-pages branch

Open natanlao opened this issue 5 years ago • 4 comments

When the gh-pages branch is built (as through the documentation build system) I get the following email from GitHub:

The page build completed successfully, but returned the following warning for the gh-pages branch: It looks like you're using GitHub Pages to distribute binary files. We strongly suggest that you use releases to ship projects on GitHub. Releases are GitHub's way of packaging and providing software to your users. You can think of it as a replacement to using downloads to provide software. We found the following file(s) which may be a good candidate for releases: .gradle/nodejs/node-v8.9.0-linux-x64/lib/node_modules/npm/node_modules/update-notifier/node_modules/boxen/node_modules/term-size/vendor/win-term-size.exe. For more information, see https://help.github.com/en/articles/about-releases.

For information on troubleshooting Jekyll see:

https://help.github.com/articles/troubleshooting-jekyll-builds

If you have any questions you can contact us by replying to this email.

I am not sure if it happens every build, but I get these emails seemingly every week or so.

This issue can be fixed by not committing binaries to gh-pages during builds. There is a partial fix in #211, which is now stale. (If my understanding of the build system is still up-to-date, which it may not be, gh-pages will likely need to be manually pushed without said binaries after being merged to master to fully address the issue.)

natanlao avatar May 14 '19 19:05 natanlao

Thanks for bringing this up, @natanlao! I can confirm that the current build system does not include your changes from #211 (with the push to get things ready for the Hinxton meeting, we opted to stick with what was working at the time).

I recently thought it could be worthwhile to move the docs (and other?) build logic/code into a separate package. This package could then just be installed and ran during the Travis job for each schema repo. As a start, I copied the latest code and config from WES (which should match the current DRS setup) here: https://github.com/ga4gh/cloud-schema-builds

My primary aim was to make it easier to keep our build strategy for the Cloud APIs consistent and in sync. However, this might be a better way to deal with the binaries-in-gh-pages problem (as opposed to more manual git tricks).

jaeddy avatar May 15 '19 01:05 jaeddy

For sure - would it be appropriate to transfer this issue to ga4gh/cloud-schema-builds then?

natanlao avatar May 16 '19 17:05 natanlao

@natanlao - I think so, but probably after we've had a chance to publicize the other repo more broadly (e.g., on the Cloud WS call). Otherwise, I'm worried most folks might miss it.

However, tagging @denis-yuen, @coverbeck, @delagoya, @susheel as heads up.

jaeddy avatar May 21 '19 17:05 jaeddy

Thanks for the heads-up, created https://github.com/ga4gh/tool-registry-service-schemas/issues/87

denis-yuen avatar May 21 '19 18:05 denis-yuen