You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Seems like the process for deploying a new version of the specification is that someone with write access will run make deploy in the spec/document folder, which will force-push a version to gh-pages. I'm wondering what we should do now
Will someone else (@rossberg ?) install bikeshed and regularly run this script?
Should I get permissions to write gh-pages?
Should I modify deploy.sh to make PRs as well and ask someone to merge them?
Should we switch to auto-deployment with Travis-CI, and give that push permissions?
My intuition is to do the fourth one, but I'm wondering if there's some reason @rossberg decided not to go that way when recently setting up the build scripts.
The text was updated successfully, but these errors were encountered:
No particular reason that this isn't automatised, sounds like a good idea. We just would need to make sure that commit rights are restricted sufficiently then, so that random persons don't have the ability to mess with the live page.
I think it makes sense to give you wirte permissions. But I'm not an admin myself, so I can't change permissions.
Nit: you shouldn't be running make deploydirectly but rather make publish.
rossberg
changed the title
Process for deploying specs
[spec] Process for deploying specs
May 3, 2018
Uh oh!
There was an error while loading. Please reload this page.
Seems like the process for deploying a new version of the specification is that someone with write access will run
make deploy
in the spec/document folder, which will force-push a version to gh-pages. I'm wondering what we should do nowMy intuition is to do the fourth one, but I'm wondering if there's some reason @rossberg decided not to go that way when recently setting up the build scripts.
The text was updated successfully, but these errors were encountered: