search

tc39 / template-for-proposals

A template for ECMAScript proposals
MIT License
120 stars 28 forks source link

Advice for Travis-CI to handle the rebuild #7

Closed littledan closed 4 years ago

littledan commented 6 years ago

I think some repositories are set up to have continuous integration build the spec. I haven't gotten my own proposals set up this way, but it seems to work well for the main spec. This way, you can even merge PRs from other contributors without having to run a rebuild step yourself as a maintainer. It'd be great if the setup for this could be ported to this repository for others to use.

ljharb commented 6 years ago

Having travis do the rebuild greatly messes up the git history by adding commits every time a master build completes; I'm working on a git hook as a way for committers to easily update the build process, as well as a CI step to fail if the build process isn't run.

domenic commented 6 years ago

Travis doing the rebuild works great if you confine it to the gh-pages branch.

domenic commented 6 years ago

The process is a bit much for most people though. Even if this repo sets up a lot of it, each repo-creator would need to do these two steps, including getting the Travis CLI, generating a SSH key, adding it to GitHub as a deploy key, and editing .travis.yml to add the encryption label. I'm not sure I'd want to inflict that on people, although for me it's pretty painless these days.

ljharb commented 6 years ago

That's fair; I think if travis was doing the build, it would make sense to use gh-pages instead of master (whereas using master is way easier when humans do the build).

I agree as well that that process is intimidatingly complex.

ljharb commented 4 years ago

This is now handled with github actions, and should also include PR branches from (properly updated) forks.