search

w3c / reporting

Reporting API
https://w3c.github.io/reporting/
Other
76 stars 36 forks source link

gh-pages copy not auto-updating #31

Closed RByers closed 7 years ago

RByers commented 7 years ago

There are commits in master (such as updating the report an issue link) which aren't currently reflected in gh-pages - so the published spec is stale. It looks (from recent PRs) like the Travis job isn't working?

RByers commented 7 years ago

Once this is fixed, we should move the couple issues mistakenly filed at https://github.com/w3c/reporting/issues/ over to this repo.

igrigorik commented 7 years ago

@plehegar set this up for us originally when we were on w3c/.. Guessing, this broke when we moved to WICG org.

plehegar commented 7 years ago

CGs can't publish in /TR. The WebPerf Group should instead republish the TR document as a Working Group Note pointing to the GitHub repo. ok to do that?

plehegar commented 7 years ago

(note that we do have a Note there now but it still contains the old content. The new Note would be pretty empty except for pointing to WICG/reporting)

RByers commented 7 years ago

I was more worried about the wicg.github.io page myself than the /TR one (but yeah making that a note pointing to the WICG page SGTM). I think fixing the wicg.github.io link is just a matter of getting bikeshed to run, right? Is it still desirable to keep the master and gh-pages branches separate, or would it be simpler to just push master into gh-pages (like other WICG repos) and have the Travis job just run bikeshed and commit the result to gh-pages?

plehegar commented 7 years ago

I suggest matching what the other WICG repos are doing it. This seems simpler to do and easier to maintain in the long run.

RByers commented 7 years ago

Although the Travis job was passing, the deploy was still failing for auth reasons. I've found updated instructions for setting this up more securely than the version we seem to have in our repo. We probably want to migrate to that method.

RByers commented 7 years ago

Of course I don't have admin access to the repo in order to add a new deploy key. This hardly seems worth the effort, how about we just rely on people editing the spec to submit the bikeshed output along with their change, then we can remove the Travis job entirely. That's what, for example, Feature Policy is doing. @patrickkettner @igrigorik @mikewest any objections?

patrickkettner commented 7 years ago

@RByers I asked @plehegar to update the keys and he went and redid the deploy script for us. Should no longer be an issue, correct?

plehegar commented 7 years ago

Make sure that the next update will go smoothly before closing this issue. I didn't test it live.

RByers commented 7 years ago

Thanks for doing this @plehegar!

It was still failing with authentication issues because Travis was still configured to run the old deploy script. I've removed the old one and updated the travis config. We'll see if it works now.

RByers commented 7 years ago

I fixed a little bug in the deploy script and have verified that it works correctly (and correctly skips deployment for no-op changes).

I've also removed the stale build output in master. The only place we have build output now is gh-pages.

Note that Travis apparently now has built-in gh-pages deployment support which would be much simpler, except that it suffers from the same problem our old script did - potentially exposing someone's personal GitHub access token to all repo collaborators (instead of just a key specific to this repo). So I'm happy just sticking with the more complex system we have here now that it's working.