You need to customize the build scripts. These script automate the publishing of your PDFs and web outputs through shell scripts on the command line.

About the build scripts

The mydoc project has 5 build scripts and a script that runs them all. These scripts will require a bit of detail to configure. Every team member who is publishing on the project should set up their folder structure in the way described here.

Get Set Up

Your command-line terminal opens up to your user name (for example, Users/tjohnson). I like to put all of my projects from repositories into a subfolder under my username called “projects.” This makes it easy to get to the projects from the command line. You can vary from the project organization I describe here, but following the pattern I outline will make configuration easier.

To set up your projects:

  1. Set up your Jekyll theme in a folder called “docs.” All of the source files for every project the team is working on should live in this directory. Most likely you already either downloaded or cloned the jekyll-documentation-theme. Just rename the folder to “docs” and move it into the projects folder as shown here.
  2. In the same root directory where the docs folder is, create another directory parallel to docs called doc_outputs. 

    Thus, your folder structure should be something like this:

    projects
    - docs
    - doc_outputs
    

    The docs folder contains the source of all your files, while the doc_outputs contains the site outputs.

Configure the Build Scripts

For the mydocs project, you’ll see a series of build scripts for each project. There are 5 build scripts, described in the following sections. Note that you really only need to run the last one, e.g., mydoc_all.sh, because it runs all of the build scripts. But you have to make sure each script is correctly configured so that they all build successfully.

mydoc_1_multiserve_pdf.sh

Here’s what this script looks like:

echo 'Killing all Jekyll instances'
kill -9 $(ps aux | grep '[j]ekyll' | awk '{print $2}')
clear


echo "Building PDF-friendly HTML site for Mydoc Writers ..."
jekyll serve --detach --config configs/mydoc/config_writers.yml,configs/mydoc/config_writers_pdf.yml
echo "done"

echo "Building PDF-friendly HTML site for Mydoc Designers ..."
jekyll serve --detach --config configs/mydoc/config_designers.yml,configs/mydoc/config_designers_pdf.yml
echo "done"

echo "All done serving up the PDF-friendly sites. Now let's generate the PDF files from these sites."
echo "Now run . mydoc_2_multibuild_pdf.sh"

After killing all existing Jekyll instances that may be running, this script serves up a PDF friendly version of the docs (in HTML format) at the destination specified in the configuration file.

Each of your configuration files needs to have a destination like this: ../doc_outputs/mydoc/adtruth-java. That is, the project should build in the doc_outputs folder, in a subfolder that matches the project name.

The purpose of this script is to make a version of the HTML output that is friendly to the Prince XML PDF generator. This version of the output strips out the sidebar, topnav, and other components to just render a bare-bones HTML representation of the content.

Customize the script with your own PDF configuration file names.

mydoc_2_multibuild_pdf.sh

Here’s what this script looks like:

# Doc Writers
echo "Building the Mydoc Writers PDF ..."
prince --javascript --input-list=../doc_outputs/mydoc/writers-pdf/prince-file-list.txt -o mydoc/files/mydoc_writers_pdf.pdf;
echo "done"

# Doc Designers
echo "Building Mydoc Designers PDF ..."
prince --javascript --input-list=../doc_outputs/mydoc/designers-pdf/prince-file-list.txt -o mydoc/files/mydoc_designers_pdf.pdf;
echo "done"

echo "All done building the PDFs!"
echo "Now build the web outputs: . mydoc_3_multibuild_web.sh"

This script builds the PDF output using the Prince command. The script reads the location of the prince-file-list.txt file in the PDF friendly output folder (as defined in the previous script) and builds a PDF.

The Prince build command takes an input parameter (--input-list=) that lists where all the pages are (prince-file-list.txt), and then combines all the pages into a PDF, including cross-references and other details. The Prince build command also specifies the output folder (-o).

The prince-file-list.txt file (which simply contains a list of URLs to HTML pages) is generated by iterating through the table of contents (mydoc_sidebar.yml) and creating a list of URLs. You can open up prince-file-list.txt in the doc output to ensure that it has a list of absolute URLs (not relative) in order for Prince to build the PDF.

This is one way the configuration file for the PDF-friendly output differs from the HTML output. (If the PDF isn’t building, it’s because the prince-file-list.txt in the output is empty or it contains relative URLs.)

The Prince build script puts the output PDF into the mydoc/mydoc/files directory. Now you can reference the PDF file in your HTML site. For example, on the homepage you can allow people to download a PDF of the content at files/adtruth_dotnet_pdf.pdf.

mydoc_3_multibuild_web.sh

Here’s what this script looks like:

kill -9 $(ps aux | grep '[j]ekyll' | awk '{print $2}')
clear

echo "Building Mydoc Writers website..."
jekyll build --config configs/doc/config_writers.yml
# jekyll serve --config configs/doc/config_writers.yml
echo "done"

echo "Building Mydoc Designers website..."
jekyll build --config configs/doc/config_designers.yml
# jekyll serve --config configs/doc/config_designers.yml
echo "done"

echo "All finished building all the web outputs!!!"
echo "Now push the builds to the server with . mydoc_4_publish.sh"

After killing all Jekyll instances, this script builds an HTML version of the projects and puts the output into the doc_outputs folder. This is the version of the content that users will mainly navigate. Since the sites are built with relative links, you can browse to the folder on your local machine, double-click the index.html file, and see the site.

The # part below the jekyll build commands contains a serve command that is there for mere convenience in case you want to serve up just one site among many that you’re building. For example, if you don’t want to build everything — just one site — you might just use the serve command instead. (Anything after # in a YAML file comments out the content.)

mydoc_4_publish.sh

Here’s what this script looks like:

echo "remove previous directory and any subdirectories without a warning prompt"
ssh yourusername@yourdomain.com 'rm -rf /var/www/html/yourpublishingdirectory'

echo "push new content into the remote directory"
scp -r -vrC ../mydoc_outputs/doc-writers yourusername@yourdomain:/var/www/html/yourpublishingdirectory

echo "All done pushing doc outputs to the server"

This script assumes you’re publishing content onto a Linux server.

Change yourusername to your own user name.

This script first removes the project folder on /var/www/html/yourpublishingdirectory site and then transfers the content from doc_outputs over to the appropriate folder in /var/www/html/yourpublishingdirectory.

Note that the delete part of the script (rm -rf) works really well. It annihilates a folder in a heartbeat and doesn’t give you any warning prompts, so make sure you have it set up correctly.

Also, in case you haven’t set up the SSH publishing without a password, see [Getting around the password prompts in SCP][mydoc_no_password_prompts_scp]. Otherwise the script will stop and ping you to enter your password for each directory it transfers.

(Optional) Push to repositories

This script isn’t included in the theme, but you might optionally decide to push the built sites into another github repository. For example, if you’re using Cloud Cannon to deploy your sites, you can have Cloud Cannon read files from a specific Github repository.

Here’s what this script looks like:

cd doc_outputs/mydoc/designers
git add --all
git commit -m "publishing latest version of docs"
git push
echo "All done pushing to Github"
echo "Here's the link to download the guides..."
cd ../../docs

This final script simply makes a commit into a Github repo for one of your outputs.

The doc_outputs/mydoc/designers contains the site output from mydoc, so when you push content from this folder into Github, you’re actually pushing the HTML site output into Github, not the mydoc source files.

Your delivery team can also grab the site output from these repos. After downloading it, the person unzips the folder and sees the website folders inside.

mydoc_all.sh

Here’s what this script looks like:

. deviceinsight_1_multiserve_pdf.sh; . deviceinsight_2_multibuild_pdf.sh; . deviceinsight_3_multibuild_web.sh; . deviceinsight_4_publish.sh;

This script simply runs the other scripts. To sequence the commands, you just separate them with semicolons. (If you added the optional script, be sure to include it here.)

After you’ve configured all the scripts, you can run them all by running . mydoc_all.sh. You might want to run this script at lunchtime, since it may take about 10 to 20 minutes to completely build the scripts. But note that since everything is now automated, you don’t have to do anything at all after executing the script. After the script finishes, everything is published and in the right location.

Test out the scripts

After setting up and customizing the build scripts, run a few tests to make sure everything is generating correctly. Getting this part right is somewhat difficult and may likely require you to tinker around with the scripts a while before it works flawlessly.

orzh-introduction

X-WAF-README

nginx-lua-module-zh-wiki

orange_about

agentzh-nginx-guide-01

pra_flame_how

orzh-introduction

X-WAF-README

nginx-lua-module-zh-wiki

orange_about

titlepage

tocpage

p1_landing_page

p1_sample1

p1_sample2

p1_sample3

p1_sample4

p1_sample5

p1_sample6

p1_sample7

titlepage

tocpage

p2_landing_page

p2_sample1

p2_sample2

p2_sample3

p2_sample4

p2_sample5

p2_sample6

p2_sample7

p2_sample8

p2_sample9

p2_sample10

p2_sample11

p2_sample12

p2_sample13

p2_sample14

titlepage

tocpage

p1_landing_page

p1_sample1

p1_sample2

p1_sample3

p1_sample4

p1_sample5

p1_sample6

p1_sample7

titlepage

tocpage

X-WAF-README

xwaf_installation

xwaf_depoly

xwaf_README

xwaf_advanced_readme

xwaf_getting_started

xwaf_faqs_readme

xwaf_roadmap

titlepage

tocpage

nginx-lua-module-zh-wiki

titlepage

tocpage

orange_api_server

orange_build_plugin

orange_dashboard_usage

orange_README

orange_basic_auth

orange_basic_info

orange_divide

orange_key_auth

orange_monitor

orange_rate_limiting

orange_redirect

orange_rewrite

orange_stat

orange_waf

orange_condition

orange_expression

orange_extraction

orange_extractor

orange_handle

orange_judge

orange_rule

orange_about

orange_contributing

orange_issues

orange_usages

titlepage

tocpage

add_new_lua_api

cosocket

get_req_body

get_url_param

helloworld

how_request_http

inline_var

install

install_on_centos

install_on_ubuntu

install_on_windows

install_osx

log_response

outtest

response

safe_sql

share_var

simple_api

sub_request

work_with_location

array_size

break

brief

build_env

call_user_func_array

capture

class

control_structrues

dot_diff

dummy_var

FFI

file

for

function_before_use

function_define

function_descrip

function_parameter

function_result

if_else

local

main

math_library

metatable

module_is_evil

module

not_nill

not_use_lib

not_use_module

object_oriented

operator

re

repeat

string_library

table_library

time_date_function

what_jit

while

pra_flame_how

pra_flame_install

pra_flame_what

pra_flame_when

pra_ngx_lua_allow_deny

pra_ngx_lua_block_io

pra_ngx_lua_cache

pra_ngx_lua_capture

pra_ngx_lua_continue_after_eof

pra_ngx_lua_debug

pra_ngx_lua_ffi

pra_ngx_lua_hot_load

pra_ngx_lua_how_one_instance_time

pra_ngx_lua_how_use_third_lib

pra_ngx_lua_keepalive

pra_ngx_lua_log

pra_ngx_lua_lua-limit

pra_ngx_lua_lua_opt

pra_ngx_lua_lua-variable-scope

pra_ngx_lua_on_abort

pra_ngx_lua_phase

pra_ngx_lua_resolve_the_domain_name

pra_ngx_lua_shared_get_keys

pra_ngx_lua_sleep

pra_ngx_lua_timer

pra_ngx_lua_use_case

pra_ngx_lua_whats_cosocket

pra_redis_auth_connect

pra_redis_dynamic_redis_module_method

pra_redis_out_package

pra_redis_pipeline

pra_redis_pub_sub_package

pra_redis_script

pra_redis_select-keeplive

pra_postgres_health_check

pra_postgres_how_to_use

pra_postgres_not_support_transaction

pra_postgres_sql_inject

pra_postgres_timeout

pra_nginx_balancer

pra_nginx_co-work_of_location

pra_nginx_if_is_evil

pra_nginx_match_uri

pra_nginx_nginx_brief

pra_nginx_nginx_local_pcre

pra_nginx_nginx_log

pra_nginx_nginx

pra_nginx_pitfalls_and_common_mistakes

pra_nginx_reverse_proxy

pra_nginx_static_file

titlepage

tocpage

candylab_clickhouse_basic

candylab_clickhouse_basic

candylab_clickhouse_basic

candylab_clickhouse_basic

candylab_clickhouse_basic

candylab_clickhouse_basic

candylab_clickhouse_basic

candylab_clickhouse_basic

candylab_clickhouse_basic

candylab_clickhouse_basic

candylab_clickhouse_basic

candylab_clickhouse_basic

candylab_clickhouse_basic

candylab_clickhouse_basic

candylab_clickhouse_basic

candylab_clickhouse_basic

candylab_clickhouse_basic

candylab_clickhouse_basic

candylab_clickhouse_basic

candylab_clickhouse_basic

candylab_clickhouse_basic

candylab_clickhouse_basic

candylab_clickhouse_basic

candylab_clickhouse_basic

candylab_clickhouse_basic

candylab_clickhouse_basic

candylab_clickhouse_basic

candylab_clickhouse_basic

candylab_clickhouse_basic

candylab_clickhouse_basic

candylab_clickhouse_basic

candylab_clickhouse_basic

candylab_clickhouse_basic

candylab_clickhouse_basic

candylab_clickhouse_basic

candylab_clickhouse_basic

candylab_clickhouse_basic

candylab_clickhouse_basic

candylab_clickhouse_basic

candylab_clickhouse_basic

candylab_clickhouse_basic

candylab_clickhouse_basic

candylab_clickhouse_basic

candylab_clickhouse_basic

candylab_clickhouse_basic

candylab_clickhouse_basic

candylab_clickhouse_basic

candylab_clickhouse_basic

candylab_clickhouse_basic

candylab_clickhouse_basic

candylab_clickhouse_basic

candylab_clickhouse_basic

candylab_clickhouse_basic

candylab_clickhouse_basic

candylab_clickhouse_basic

candylab_clickhouse_basic

candylab_clickhouse_basic

candylab_clickhouse_basic

candylab_clickhouse_basic

candylab_clickhouse_basic

candylab_clickhouse_basic

candylab_clickhouse_basic

candylab_clickhouse_basic

candylab_clickhouse_basic

candylab_clickhouse_basic

candylab_clickhouse_basic

candylab_scan_port

candylab_common_sites_log_system

candylab_graylog_clickhouse

candylab_clickhouse_basic

candylab_logs_and_gateway

candylab_sec_system_arch

candylab_logs_dsl_waf

candylab_opensock_list

candylab_opensock_practice

candylab_opensock_email

candylab_base_on_openresty_waf

candylab_dsl_waf

candylab_honeypot_system

candylab_monitor_redis

candylab_threat_replay

candylab_pcap_monitor

candylab_monitor_website

candylab_openrestyplus_waf

candylab_windows_bigdata

candylab_clickhouse_basic

candylab_clickhouse_basic

candylab_clickhouse_basic

candylab_clickhouse_basic

candylab_clickhouse_basic

candylab_clickhouse_basic

candylab_clickhouse_basic

candylab_clickhouse_basic

candylab_clickhouse_basic

candylab_clickhouse_basic

titlepage

tocpage

agentzh-nginx-guide-01

agentzh-nginx-guide-02

agentzh-nginx-guide-03

agentzh-nginx-guide-04

agentzh-nginx-guide-05

agentzh-nginx-guide-06

agentzh-nginx-guide-07

agentzh-nginx-guide-08

mydoc_hyperlinks.html#automatedlinks

mydoc_hyperlinks.html#bookmarklinks

mydoc_pages.html#someIdTag

news

nginx-lua-module-zh-wiki

nginx-development-guide-zh

orange_about

X-WAF-README

pra_flame_how

Tags: publishing