Configure an automated build into HTML

[terales]

It's rather complicated to check out the current version of DocBook.

I suggest to set up an automatic build into GitHub pages. So non-devs could quickly read the latest version.

What do you think about it?
If it's ok with you, I can prepare a PR, but it would require some guided configuration done by one of the repo collaborators.

[DavidFatDavidF]

Hi @terales, this is in fact in making.
The only current DocBook draft is being published to our github.io pages in HTML and PDF preview versions. Our webpage content is in the docs folder. We didn't publicize that widely as it is yet very rudimentary..
So far we are using only preliminary, built-in oXygen transforms but Jano is working on modified stylesheets for HTML and PDF that will be tweaked and branded to our needs.
We will publish those stylesheets along with the template once ready..
If you want to use those to automate the build, you're most welcome..
However not sure if we can fully automate the build on GitHub side, because a Saxon licence would be needed to run that..

[terales]

Oh, I see https://galaglobal.github.io/TAPICC/
Maybe it worse to add a link to README? Do you need a PR for this?

---

However not sure if we can fully automate the build on GitHub side because a Saxon license would be needed to run that

I'm basically thinking about integration with Travis CI: on each commit into the master branch, it would build it and, if build succeeds, commit it into gh-pages branch. GitHub would automatically redeploy assets from there.

It's okay to have any licensed tools because their keys could be stored in the secure environment variables at Travis CI.

I would be able to set up working configuration as an example, but eventually, you would have to create the same configuration from my instructions to keep project closed.

[DavidFatDavidF]

Alexander, I hear from Jano that ur active in WG4, meaning uv the legal signed.. I will ask Laura to give you write access, so that you can make the Travis integration. In fact we added Travis a while ago but no one had time to play with it ;-)
Your help here would be most welcome..
I would wait with publicizing the github.io webpage for a bit.. But you can start playing with the automated Travis build right away..
Cheers and thanks dF

[laurabrandon]

Hi All -- I just sent an invitation to @terales for write access.

Thanks,
Laura

[JanHusarcik]

Hi @terales

if that's OK with you, I'll assign this item to you. Re the output:

• to create HTML we need a XSLT processor, I think we can use a free version of Saxon
• for PDF we need FO Processor, which is opensource, so there should be no problem with it

Jan

[terales]

Sure, thanks!

[terales]

Blocked by #5

[DavidFatDavidF]

@terales where did you get your xslt used for the build? The error message seemed to be that the xslt wasn't one.. I can commit the current oXygen transforms I am using to build and that store the outputs into my local doc folder..

[terales]

where did you get your xslt used for the build?

I believe that all required files, except binaries and files, included from third-party dependencies, should be in the repository.

With this idea in mind I was trying to use /docbook/T1/WG3/XLIFF-EM-BP.xml_xslt file as in the example command from suggested DocBook README:

java -jar saxon9pe.jar -xsl:./docbook/T1/WG3/XLIFF-EM-BP.xml_xslt -s:./docbook/T1/WG3/ -o:./docs/

---

I'm surprised a bit that you've merged draft of the README without addressing questions from PR #6. Sorry for not being clear. Let me explain what I was expecting based on my experience on open source software projects.

My initial idea was like this:

1. I create a draft of DocBook building instructions (WIP prefix at PR mean work in progress, do not merge).
2. Someone who can build the DocBook comes and either answer my questions in comments so I would update instruction or commit fixed instruction by himself.
3. I would follow the instruction and verify that it could be reproduced from the clean machine by a person who just follows the instruction.
4. If there are any troubles I'll ask for clarifications or missing files there.
5. I remove the WIP suffix and ask to verify the instruction inside this PR.
6. After positive feedback, I or someone else will merge it into the master branch.

Now I see that your approach is different. Can you share your plan, please?

[DavidFatDavidF]

You are right, I shouldn't have merged #6
It seemed to me on cursory reading that the #6 6 was already resolved..
Is there a way to reopen #5 and #6?

[terales]

Let me revert the merge and open a new PR

[terales]

Done: #7

[terales]

I wasn't able to replicate settings from paid publishing software within scripting open-source environment.