Trigger self-deploy for fork, on <self>/gh-pages branch.

[Carreau]

If the current repository is python/peps:

• build only on master.
• deploy to root of gh-pages, meaning that peps should be visible at:
  https://python.github.io/peps/ (CNAMe can be added later to be
  accessible from peps.python.org

If the current repository is not python/peps:

• build unless the branch is master or gh-pages (we want to avoid
  recursion right?)
• deploy to <username>.github.io/peps/<branchname>/

This try to deploy only if DEPLOY_KEYis set.

---

Take 2 on #17

@brettcannon said in #17:

Save auto-deploy for a separate PR. I have no issue with Travis zipping up the built PEPs as a build artifact that people can download to view post-CI if they want to see what the rendered version.

The problem is that the code to do it have to be in python/peps otherwise it requires people to modify their .travis.yml for every PR, which you obviously don't want to merge.
And uploading a zip needs credentials as well. Pushing back on Gh-Pages seem the simpler as it also allow to see the rendered version with need to download-zip, unpack, and test locally (which you can't do on phones)

[berkerpeksag]

I still can't see the benefit of adding this. The converter in python.org uses different a CSS file and rewrites the HTML files created by pep2html.py (search for "pep" on pydotorg issue tracker to see inconsistencies).

Georg's idea in #5 (comment) is more preferable in my opinion.

[Carreau]

I don't disagree with the comment in #5 and this does not prevent it
either. The point is that for now there is still a large number of
text/plain only pep. So it can't build on RTD.

Brett mentionned that it would be nice to have auto build of the peps, Why
not on peps.p Python.org thus if pep migrate there the current style and
build process is irrelevant. (Cf #2 and #3 for refs).

This is my attempt at fixing that : use Travis to build and deploy a
version.

Regardless of wether you want autobuild, the part about user deploy on
they own gh-pages allow your contributor (if they like to) and your
reviewed to review styles changes to the (future) build pep website.

Unless there is an actual disagreement on the fact that peps should not
move to peps.python.org, or that you actually with to manually want to
build the HTML version of each pep everytime there is a major submission.

Finally as a contributor it simplify my workflow, when I convert a pep from
plaintext to rst, or any other modifications, I can just push on github and
have a rendered version available a few minutes later. I can do that in
parallel on many branches without having to wait for a local build. Which
is extremely useful.
On Jun 20, 2016 12:21, "Berker Peksag" notifications@github.com wrote:

I still can't see the benefit of adding this. The converter in python.org
uses different a CSS file and rewrites the HTML files created by
pep2html.py (search for "pep" on pydotorg issue tracker to see
inconsistencies).

Georg's idea in #5 (comment)
#5 (comment) is more
preferable in my opinion.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#25 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/AAUez67zTKyZqMoAyo8RVH7JRYw3tGt_ks5qNugjgaJpZM4I6AXW
.

[berkerpeksag]

I think there is a misunderstanding here. Unless I'm missing something there is no concrete plan about peps.python.org yet.

#3 is briefly mentioned about RtD but there is no discussion about what is going to happen to the current infrastructure (A list of open questions: Are we still going to use genpepindex.py, pep2html.py and pep0 package or clean everything and switch to use Sphinx like proposed in #2? Are we going to use the PEP converter in python.org or just delete the peps application in www.python.org and redirect python.org/dev/peps/pep-XXX/ to peps.python.org/pep-XXXX/? Are we going to host it on rtd.org or set up our RtD instance? New theme or use the default one RtD?)

Finally as a contributor it simplify my workflow, when I convert a pep from
plaintext to rst, or any other modifications, I can just push on github and
have a rendered version available a few minutes later.

Or you can build the files you've changed in your computer in a few seconds, verify they look fine, and send a pull request.

[brettcannon]

I think the point @Carreau is making is that it's easier if the files are simply there to view if you're doing some work in the browser. #1 would actually go a long way to helping with that, though, since you would get rich renderings and diffs. But that doesn't cover the header fields which simply get mangled.

My question is where did the travis.sh file come from? Is it boilerplate from somewhere so maintenance going forward is easy (which is my real worry with this)?

[Carreau]

My question is where did the travis.sh file come from?

No I wrote it from scratch, with inspiration from what is used on matplotlib/matplotlib and ipython/ipython-website. There are similar packages that do that on npm, but not exactly what is needed there.

Seeing the discussion. I'm fine if this is closed, you should just mentioned in #3 and #2 that the decision of exactly what would become of the peps on Python.org should be decided first.

[brettcannon]

I've collapsed #2 and #3 into a single issue (as #2) as there's no point in keeping them separate since they depend on each other so much in terms of motivation.