Jump to page: 1 2
Thread overview
[howto] Serve ddox documentation on github.io deployed by Travis CI
Jan 08
Seb
Jan 08
Seb
Jan 13
Seb
Feb 01
Denis F
Feb 01
Denis F
January 08
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.)
January 08
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
January 08
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:
>> Here's how: https://gist.github.com/veelo/f7668510bad2e8c9212ab66104541fcc
>
> FYI: You could reduce the size of the `travis.yml`.
> See e.g.:
>
> https://github.com/thaven/oauth/pull/12

That moves a simple section from `.travis.yml` to a more complicated script `travis.sh`.
January 08
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:
>> On Monday, 8 January 2018 at 22:06:44 UTC, Bastiaan Veelo wrote:
>>> Here's how: https://gist.github.com/veelo/f7668510bad2e8c9212ab66104541fcc
>>
>> FYI: You could reduce the size of the `travis.yml`.
>> See e.g.:
>>
>> https://github.com/thaven/oauth/pull/12
>
> That moves a simple section from `.travis.yml` to a more complicated script `travis.sh`.

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!
January 08
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:
>> 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:
>>>> Here's how: https://gist.github.com/veelo/f7668510bad2e8c9212ab66104541fcc
>>>
>>> FYI: You could reduce the size of the `travis.yml`.
>>> See e.g.:
>>>
>>> https://github.com/thaven/oauth/pull/12
>>
>> That moves a simple section from `.travis.yml` to a more complicated script `travis.sh`.
>
> I was talking about e.g. `libssl-dev`, but I saw you already adjusted that.

OK that's what I noticed from your reference :-)

> 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.

dub is great!

> Anyways, great document - thanks a lot for sharing!

My pleasure.
January 10
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?
January 10
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/548ffbcdae99d752da02

> 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.
January 10
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/548ffbcdae99d752da02

For 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
January 10
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.
January 13
On Wednesday, 10 January 2018 at 08:50:37 UTC, Bastiaan Veelo wrote:
>> 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.

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.
« First   ‹ Prev
1 2