@fil: why is reworking the docs repo needed for automatic deployment? @steve: could you merge it then? I'm far too rusty on my Cordova-ing to remember how to set up my remotes to push to the ASF repo, sorry. :(
Kindly, Dmitry > On Sep 13, 2017, at 1:08 PM, Filip Maj <maj....@gmail.com> wrote: > > We have an issue posted to make docs publishing automatic: > https://issues.apache.org/jira/browse/CB-13162 > > Not to derail the topic, but there is a longer wishlist in that issue, > and I do think achieving the goals in that issue would require > reworking the docs repository quite a bit. We can discuss details in > the issue thread. > > On Wed, Sep 13, 2017 at 9:47 AM, Dmitry Blotsky > <dmitry.blot...@gmail.com> wrote: >> Yes, ideally our deployment process should be automated. Also, it should >> *not* be an SVN commit. It should be an rsync or an scp command. I would >> support any initiatives to move to either one of those. If we had automated >> deployment, this discussion would be moot. >> >> How much would it cost us to just have a VPS with nginx? >> >> Switching to the topic of deployment docs now. Thanks, Shaz, for bringing >> this up in discussion. My opinion was that we shouldn't have impactful >> commands be copy-paste-able, which is why I had the instruction to commit in >> paragraph text. I think that if a committer doesn't read the full text of >> the deployment docs, *they should not be deploying*. I can see the argument >> that if they do read the text but just don't know *how* to commit in SVN, >> it's annoying to search. However at the top of that section is an explicit >> link to a quick SVN tutorial. I understand that not everyone reads the fine >> print, but IMO committers should, and we should explicitly discourage that >> behaviour. >> >> Ultimately I'm going to defer to Shaz here, but I think it's important to >> consider the benefits of making deployment *feel* more serious by making >> RTFD necessary. >> >> Kindly, >> Dmitry >> >>> On Sep 13, 2017, at 6:30 AM, Jan Piotrowski <piotrow...@gmail.com> wrote: >>> >>> I am actually surprised deploying is a manual process at all. >>> Having read the steps, I understand why of course. >>> >>> As a person that jumps in on all kinds of projects, I absolutely >>> prefer docs that list each and every little step needed (including all >>> the `cd` etc). >>> >>> The need for manual steps or checks could be emphasized by using a >>> numbered list or checklist for the individual steps. >>> >>> (Will this stay on SVN even after the repo switch to Github? Merging >>> and `gh-pages` is so nice and simple) >>> >>> -J >>> >>> 2017-09-13 9:02 GMT+02:00 Shazron <shaz...@gmail.com>: >>>> This relates solely to instructions on how to *build* the site, and not the >>>> contents of the site itself. >>>> >>>> Bringing this up here for discussion since a committer wants to revert a >>>> change by another committer, and there is potential for disagreement. >>>> >>>> The pull request to revert is here: >>>> https://github.com/apache/cordova-docs/pull/729 >>>> >>>> There has been discussion on the original change here: >>>> https://github.com/apache/cordova-docs/commit/96c5ab0f98c0b62160661dcd9a9db5549fe43f94 >>>> >>>> Two issues here: >>>> 1. The change from `gulp build --prod` to `npm run serve` >>>> 2. This instruction here (not reverted in the PR): >>>> https://github.com/apache/cordova-docs/commit/d61f3ddc84dac4b013c0607230b9cf10921a416b >>>> >>>> Issue (1) has some discussion in the GH link above for the original change. >>>> >>>> Issue (2) there was some discussion in the Cordova Slack, that the reason >>>> the `svn commit` wasn't there in the first place is to prevent copy/paste >>>> of the commands without going through the changes step by step since >>>> deploying to a site is an expensive operation that can screw up the site if >>>> proper care was not done. >>>> >>>> My reason for adding the command was that the instructions are not complete >>>> (when I had to do it myself when updating the docs for cordova-ios >>>> release). I understand the rationale, but the instructions seem incomplete >>>> (especially for new committers that haven't heard of SVN, I know they can >>>> Google it, but that's more friction) and my other reason is: we should >>>> trust that committers will do the right thing. >>>> >>>> Not to make a mountain out of a mole-hill but it's important that these >>>> revert discussions be out in the open so as misunderstandings/hurt feelings >>>> don't occur, and we can nip it in the bud. >>>> >>>> Thoughts from the community? >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org >>> For additional commands, e-mail: dev-h...@cordova.apache.org >>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org >> For additional commands, e-mail: dev-h...@cordova.apache.org >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > For additional commands, e-mail: dev-h...@cordova.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
