digitalmars.D.announce - [howto] Serve ddox documentation on github.io deployed by Travis CI
- Bastiaan Veelo (13/13) Jan 08 2018 I was looking for this, it wasn't there, so I wrote it myself.
- Seb (4/17) Jan 08 2018 FYI: You could reduce the size of the `travis.yml`.
- Bastiaan Veelo (3/9) Jan 08 2018 That moves a simple section from `.travis.yml` to a more
- Seb (9/21) Jan 08 2018 I was talking about e.g. `libssl-dev`, but I saw you already
- Bastiaan Veelo (4/26) Jan 08 2018 dub is great!
- Martin Nowak (9/13) Jan 09 2018 Using Travis' built-in deployment toGithub Pages is indeed a bit
- Bastiaan Veelo (12/16) Jan 10 2018 Yes it does make it easier. But I chose not to because of
- Bastiaan Veelo (5/10) Jan 10 2018 For clarity: following the howto [2] you do the encryption
- Martin Nowak (8/13) Jan 12 2018 What do you mean with "taking care of it"?
- Seb (3/18) Jan 12 2018 https://github.com/dlang/dub/pull/1326#issuecomment-357233196
- Jacob Carlborg (5/14) Jan 13 2018 Perhaps to automatically generate documentation for all packages on
- Bastiaan Veelo (8/21) Jan 13 2018 Yes that is what I meant, sorry for being vague. It’s been
- Martin Nowak (14/36) Jan 18 2018 I don't think it's good idea to centralize this.
- Denis F (7/29) Feb 01 2018 I like this idea because:
- Denis F (2/2) Feb 01 2018 (3) Docs from proposed site can be easily wrapped into
- Bastiaan Veelo (2/4) Jan 10 2018 I included a link to bloom at the bottom of the howto.
I was looking for this, it wasn't there, so I wrote it myself. - You have a D poject on GitHub? - You want your documentation online? For free? - You think it should always be up to date without you lifting a finger? - You wonder how? Here's how: https://gist.github.com/veelo/f7668510bad2e8c9212ab66104541fcc I'm looking forward to see lots of well written documentation! Cheers, Bastiaan. (It turned out as a gist. I don't mind it being recycled on wiki's, blog's or elsewhere.)
Jan 08 2018
On Monday, 8 January 2018 at 22:06:44 UTC, Bastiaan Veelo wrote:I was looking for this, it wasn't there, so I wrote it myself. - You have a D poject on GitHub? - You want your documentation online? For free? - You think it should always be up to date without you lifting a finger? - You wonder how? Here's how: https://gist.github.com/veelo/f7668510bad2e8c9212ab66104541fcc I'm looking forward to see lots of well written documentation! Cheers, Bastiaan. (It turned out as a gist. I don't mind it being recycled on wiki's, blog's or elsewhere.)FYI: You could reduce the size of the `travis.yml`. See e.g.: https://github.com/thaven/oauth/pull/12
Jan 08 2018
On Monday, 8 January 2018 at 22:12:17 UTC, Seb wrote:On Monday, 8 January 2018 at 22:06:44 UTC, Bastiaan Veelo wrote:That moves a simple section from `.travis.yml` to a more complicated script `travis.sh`.Here's how: https://gist.github.com/veelo/f7668510bad2e8c9212ab66104541fccFYI: You could reduce the size of the `travis.yml`. See e.g.: https://github.com/thaven/oauth/pull/12
Jan 08 2018
On Monday, 8 January 2018 at 22:20:37 UTC, Bastiaan Veelo wrote:On Monday, 8 January 2018 at 22:12:17 UTC, Seb wrote:I was talking about e.g. `libssl-dev`, but I saw you already adjusted that. Note that with the next vibe.d release (0.8.3), you can also drop libevent-dev as vibe-core will become the default. You could already do this today with `dub build -b ddox --override-config="vibe-d:core/vibe-core"`, but Ddox that might require the latest vibe.d and vibe-core. Anyways, great document - thanks a lot for sharing!On Monday, 8 January 2018 at 22:06:44 UTC, Bastiaan Veelo wrote:That moves a simple section from `.travis.yml` to a more complicated script `travis.sh`.Here's how: https://gist.github.com/veelo/f7668510bad2e8c9212ab66104541fccFYI: You could reduce the size of the `travis.yml`. See e.g.: https://github.com/thaven/oauth/pull/12
Jan 08 2018
On Monday, 8 January 2018 at 23:06:04 UTC, Seb wrote:On Monday, 8 January 2018 at 22:20:37 UTC, Bastiaan Veelo wrote:OK that's what I noticed from your reference :-)On Monday, 8 January 2018 at 22:12:17 UTC, Seb wrote:I was talking about e.g. `libssl-dev`, but I saw you already adjusted that.On Monday, 8 January 2018 at 22:06:44 UTC, Bastiaan Veelo wrote:That moves a simple section from `.travis.yml` to a more complicated script `travis.sh`.Here's how: https://gist.github.com/veelo/f7668510bad2e8c9212ab66104541fccFYI: You could reduce the size of the `travis.yml`. See e.g.: https://github.com/thaven/oauth/pull/12Note that with the next vibe.d release (0.8.3), you can also drop libevent-dev as vibe-core will become the default. You could already do this today with `dub build -b ddox --override-config="vibe-d:core/vibe-core"`, but Ddox that might require the latest vibe.d and vibe-core.dub is great!Anyways, great document - thanks a lot for sharing!My pleasure.
Jan 08 2018
On Monday, 8 January 2018 at 22:06:44 UTC, Bastiaan Veelo wrote:Cheers, Bastiaan. (It turned out as a gist. I don't mind it being recycled on wiki's, blog's or elsewhere.)Using Travis' built-in deployment toGithub Pages is indeed a bit simpler. Also adding the token in Travis' settings page instead in the yaml makes things easier. I've changed my blueprint project accordingly https://github.com/MartinNowak/bloom/blob/1e2c2729a2618962e596d68635c5e7e46def2189/.travis.yml. Maybe worthwile to add this scaffolding to dub or some other tool? Anyone volunteering?
Jan 09 2018
On Wednesday, 10 January 2018 at 02:59:38 UTC, Martin Nowak wrote: [...]Also adding the token in Travis' settings page instead in the yaml makes things easier.Yes it does make it easier. But I chose not to because of comments on [1] (notably by ilg-ul). I don't know if I am being paranoid but it's been said that GitHub tokens give access to all repositories and just pasting an unencrypted token in some web interface is a security risk. For a howto I figured the safer route is better. [1] https://gist.github.com/vidavidorra/548ffbcdae99d752da02Maybe worthwile to add this scaffolding to dub or some other tool? Anyone volunteering?This could be a good idea. Probably even better is to let code.dlang.org take care of it, which would make the whole token issue and setup obsolete.
Jan 10 2018
On Wednesday, 10 January 2018 at 08:50:37 UTC, Bastiaan Veelo wrote:I don't know if I am being paranoid but it's been said that GitHub tokens give access to all repositories and just pasting an unencrypted token in some web interface is a security risk. For a howto I figured the safer route is better. [1] https://gist.github.com/vidavidorra/548ffbcdae99d752da02For clarity: following the howto [2] you do the encryption locally and limit access to the repository in question. [2] https://gist.github.com/veelo/f7668510bad2e8c9212ab66104541fcc
Jan 10 2018
On Wednesday, 10 January 2018 at 08:50:37 UTC, Bastiaan Veelo wrote:What do you mean with "taking care of it"? It's a bit of a hen and egg problem, first you need a project before you can register it with code.dlang.org. So that seems like a sub-optimal place to help with project setup. Dub init would be much better suited. We should figure out to make the existing init templates extensible anyhow.Maybe worthwile to add this scaffolding to dub or some other tool? Anyone volunteering?This could be a good idea. Probably even better is to let code.dlang.org take care of it, which would make the whole token issue and setup obsolete.
Jan 12 2018
On Saturday, 13 January 2018 at 04:59:25 UTC, Martin Nowak wrote:On Wednesday, 10 January 2018 at 08:50:37 UTC, Bastiaan Veelo wrote:Citing Sönke:[...]What do you mean with "taking care of it"? It's a bit of a hen and egg problem, first you need a project before you can register it with code.dlang.org. So that seems like a sub-optimal place to help with project setup. [...]The whole dub init -t feature is planned to be replaced by a more general approach, so it would be rather wasteful to invest more time than necessary in this. The new approach basically would simply look for a ":example" (or similar) sub package for the first dependency specified to dub init, uses that as the base for the newly created package, and would then just adjust the recipe according to the remaining init parameters.https://github.com/dlang/dub/pull/1326#issuecomment-357233196
Jan 12 2018
On 2018-01-13 05:59, Martin Nowak wrote:On Wednesday, 10 January 2018 at 08:50:37 UTC, Bastiaan Veelo wrote:Perhaps to automatically generate documentation for all packages on code.dlang.org and publish it there as well. -- /Jacob CarlborgWhat do you mean with "taking care of it"?Maybe worthwile to add this scaffolding to dub or some other tool? Anyone volunteering?This could be a good idea. Probably even better is to let code.dlang.org take care of it, which would make the whole token issue and setup obsolete.
Jan 13 2018
On Saturday, 13 January 2018 at 10:02:18 UTC, Jacob Carlborg wrote:On 2018-01-13 05:59, Martin Nowak wrote:Yes that is what I meant, sorry for being vague. It’s been suggested before I think. It would be a lot more work than what you are suggesting and one does not have to exclude the other: a bot could clone the project repositories and generate documentation for each, without project owners needing to manage tokens.On Wednesday, 10 January 2018 at 08:50:37 UTC, Bastiaan Veelo wrote:Perhaps to automatically generate documentation for all packages on code.dlang.org and publish it there as well.What do you mean with "taking care of it"?Maybe worthwile to add this scaffolding to dub or some other tool? Anyone volunteering?This could be a good idea. Probably even better is to let code.dlang.org take care of it, which would make the whole token issue and setup obsolete.
Jan 13 2018
On Saturday, 13 January 2018 at 11:42:42 UTC, Bastiaan Veelo wrote:On Saturday, 13 January 2018 at 10:02:18 UTC, Jacob Carlborg wrote:I don't think it's good idea to centralize this. First the existing tools are easy enough to use, though some articles are necessary to spread the knowledge. Second it'd put more burden on very few people that are already maintaining an unproportionate part of the overall ecosystem. Third ppl. might want to use different doc generators, styles, or host a project site. Fourth you create new problems like CSRF when hostings docs on one domain, hence github pages have one subdomain per user. We might want to add a configurable doc link to project settings on the registry, but the Readme is already a good or even better place.On 2018-01-13 05:59, Martin Nowak wrote:Yes that is what I meant, sorry for being vague. It’s been suggested before I think. It would be a lot more work than what you are suggesting and one does not have to exclude the other: a bot could clone the project repositories and generate documentation for each, without project owners needing to manage tokens.On Wednesday, 10 January 2018 at 08:50:37 UTC, Bastiaan Veelo wrote:Perhaps to automatically generate documentation for all packages on code.dlang.org and publish it there as well.What do you mean with "taking care of it"?Maybe worthwile to add this scaffolding to dub or some other tool? Anyone volunteering?This could be a good idea. Probably even better is to let code.dlang.org take care of it, which would make the whole token issue and setup obsolete.
Jan 18 2018
On Saturday, 13 January 2018 at 11:42:42 UTC, Bastiaan Veelo wrote:On Saturday, 13 January 2018 at 10:02:18 UTC, Jacob Carlborg wrote:I like this idea because: 1) it is more secure than allow to access Travis CI to my public repos 2) this can encourage writing documentation in those projects that not thinked about documentationOn 2018-01-13 05:59, Martin Nowak wrote:Yes that is what I meant, sorry for being vague. It’s been suggested before I think. It would be a lot more work than what you are suggesting and one does not have to exclude the other: a bot could clone the project repositories and generate documentation for each, without project owners needing to manage tokens.On Wednesday, 10 January 2018 at 08:50:37 UTC, Bastiaan Veelo wrote:Perhaps to automatically generate documentation for all packages on code.dlang.org and publish it there as well.What do you mean with "taking care of it"?Maybe worthwile to add this scaffolding to dub or some other tool? Anyone volunteering?This could be a good idea. Probably even better is to let code.dlang.org take care of it, which would make the whole token issue and setup obsolete.
Feb 01 2018
(3) Docs from proposed site can be easily wrapped into DevDocs/Zeal/Dash docs for comfort offline usage.
Feb 01 2018
On Wednesday, 10 January 2018 at 02:59:38 UTC, Martin Nowak wrote:I've changed my blueprint project accordingly https://github.com/MartinNowak/bloom/blob/1e2c2729a2618962e596d68635c5e7e46def2189/.travis.yml.I included a link to bloom at the bottom of the howto.
Jan 10 2018