You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
* Revert "Add dynamic config & allow vars for non-config builds (#49)"
This reverts commit 006f16f.
We want to reapply these changes and reconcile the conflicts without overwriting anything.
* Merge --cvar into --var
* bugfix: handle adding variables to emptyset
* Bump verion to 0.9.1
Copy file name to clipboardExpand all lines: README.adoc
+92-13Lines changed: 92 additions & 13 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,4 +1,6 @@
1
1
= LiquiDoc
2
+
:toc: preamble
3
+
2
4
// tag::overview[]
3
5
LiquiDoc is a documentation build utility for true single-sourcing of technical content and data.
4
6
It is especially suited for documentation projects with various required output formats, but it is intended for any project with complex, versioned input data for use in docs, user interfaces, and even back-end code.
@@ -876,24 +878,92 @@ See <<per-build-properties-files>>.
876
878
877
879
=== Deploy Operations
878
880
879
-
It's not clear how deeply we will delve into deploy operations, since other build systems (such as rake) would seem far more suitable.
880
-
For testing purposes, however, spinning up a local webserver with the same stroke that you build a site is pretty rewarding and time saving.
881
+
Mainstream deployment platforms are probebly better suited to tying all your operations together, but we plan to bake a few common operations in to help you get started.
882
+
For true build-and-deployment control, consider build tools such as Make, Rake, and Gradle, or deployment tools like Travis CI, CircleCI, and Jenkins.
883
+
884
+
==== Jekyll Serve
885
+
886
+
For testing purposes, however, spinning up a local webserver with the same stroke that you build a site is pretty rewarding and time saving, so we'll start there.
881
887
882
888
For now, this functionality is limited to adding a `--deploy` flag to your `liquidoc` command.
883
889
This will attempt to serve files from the *destination* set for the associated Jekyll build.
884
890
885
891
[WARNING]
886
892
Deployment of Jekyll sites is both limited and untested under nonstandard conditions.
887
893
894
+
==== Algolia Search Indexing for Jekyll
895
+
896
+
If you're using Jekyll to build sites, LiquiDoc makes indexing your files with the Algolia cloud search service a matter of configuration.
897
+
The heavy lifting is performed by the jekyll-algolia plugin, but LiquiDoc can handle indexing even a complex site by using the same configuration that built your HTML content (which is what Algolia actually indexes).
898
+
888
899
[NOTE]
889
-
The <<config-settings-matrix,*Config Settings Matrix*>> has moved to the <<reference,Reference Section>>.
900
+
You will need a free community (or premium) link:https://www.algolia.com/users/sign_up/hacker[Algolia account] to take advantage of Algolia's indexing service and REST API.
901
+
Simply create a named index, then visit the API Keys to collect the rest of the info you'll need to get going.
902
+
903
+
Two hard-coding steps are required to prep your source to handle Algolia index pushes.
904
+
905
+
. Add a block to your main Jekyll configuration file.
<2> From the API Keys screen of your Algolia interface.
918
+
<3> List as many extensions as apply, separated by commas.
919
+
920
+
. Add a block to your build config.
921
+
+
922
+
[source,yaml]
923
+
----
924
+
- action: render
925
+
data: globals.yml
926
+
builds:
927
+
- backend: jekyll
928
+
properties:
929
+
files:
930
+
- _configs/jekyll-global.yml
931
+
- _configs/jekyll-portal-1.yml
932
+
arguments:
933
+
destination: build/site/user-basic
934
+
attributes:
935
+
portal_term: Guide
936
+
search:
937
+
index: 'portal-1'
938
+
----
939
+
+
940
+
The `index:` parameter is for the name of the index you are pushing to.
941
+
(An Algolia “app” can have multiple “indices”.)
942
+
If you have
943
+
944
+
Now you can call your same LiquiDoc build command with the `--search-index-push` or `--search-index-dry` flags along with the `--search-api-key='your-admin-api-key-here'` argument in order to invoke the indexing operation.
945
+
The `--search-index-dry` flag merely tests content packaging, whereas `--search-index-push` connects to the Algolia REST API and attempt to push your content for indexing and storage.
This operation performs a complete build, including each render operation, before the Algolia plugin processes content and pushes each build to the indexing service, in turn.
954
+
955
+
[TIP]
956
+
To add modern site search for your users, add link:https://community.algolia.com/instantsearch.js/[Algolia's InstantSearch functionality] to your front end!
890
957
891
958
== Configuring a LiquiDoc Build
892
959
893
960
In order to seriously explore and instruct this tool's ability to single-source a product's entire docs-integrated codebase, I have set out on a project for LiquiDoc to eat its own proverbial dog food.
894
961
That is, I'm using LiquiDoc to document LiquiDoc in a separate repository -- one which treats the LiquiDoc gem repository (_this_ repo) as a Git submodule.
895
962
That is, for purposes of coding, _all_ of the *liquidoc-gem* repo's code is accesible by way of an alias path, `products/liquidoc-gem`, from the base of the *liquidoc-docs* project.
896
963
964
+
[NOTE]
965
+
The <<config-settings-matrix,*Config Settings Matrix*>> has moved to the <<reference,Reference Section>>.
966
+
897
967
=== Gem Repo as Submodule
898
968
899
969
I am on record as prefering to _keep docs source in the same codebase as that of the product they reference_.
@@ -988,8 +1058,8 @@ That is, your config files can contain variables, conditionals, and iterative lo
988
1058
All you have to do is (1) add Liquid tags to your YAML configuration file and (2) either (a) pass at least one _config variable_ to it when running your `liquidoc` command or (b) pass it the `--parseconfig` flag.
989
1059
990
1060
Let's explore that second requirement.
991
-
If the Liquid markup in your config file expects variables, pass those variables on the `liquidoc` CLI using `--configvar key=value`.
992
-
Otherwise, if you are not passing variables to your config, instruct LiquiDoc to parse the config file using the `parseconfig` CLI option.
1061
+
If the Liquid markup in your config file expects variables, pass those variables on the `liquidoc` CLI using `--var key=value`.
1062
+
Otherwise, if you are not passing variables to your config, instruct LiquiDoc to parse the config file using the `--parseconfig` CLI flag.
993
1063
For example, this might be the case if your config merely contains some simple looping functionality to process lots of files.
994
1064
995
1065
[[config-variables]]
@@ -1011,16 +1081,19 @@ Let's first take a look at a sample dynamic configuration to see if we can under
1011
1081
1012
1082
This config file wants to build a product datasheet for a specific product, which it expects to be indicated by a config variable called `product_slug`.
1013
1083
1014
-
Config variables are passed using the `--configvar varname='var val'` format, where `varname` is any key that exists as a Liquid variable in your config file, and `'var val'` is its value, wrapped in single quotes.
1084
+
Config variables are passed using the `--var varname='var val'` format, where `varname` is any key that exists as a Liquid variable in your config file, and `'var val'` is its value, wrapped in single quotes.
1015
1085
Let's say in this case, we want to generate the datasheet for the Windows Enterprise edition of our product.
To set the values of `vars.edition` and `vars.env` in the config file, add for instance `--configvar edition=basic --configvar env=staging`
1156
+
To set the values of `vars.edition` and `vars.env` in the config file, add for instance `--var edition=basic --var env=staging`
1084
1157
1085
1158
==== Constraining Build Options with Dynamic Configuration
1086
1159
@@ -1113,7 +1186,7 @@ For instance,
1113
1186
{% endif %}
1114
1187
----
1115
1188
1116
-
With a build config like this, optionally invoking `--configvar recipe=nopdf`, for instance, will suppress the PDF substep during the build routine.
1189
+
With a build config like this, optionally invoking `--var recipe=nopdf`, for instance, will suppress the PDF substep during the build routine.
1117
1190
1118
1191
==== Generating Starter Files with Dynamic Configs
1119
1192
@@ -1125,7 +1198,7 @@ Once you're comfortable with the concept of <<dynamic-config,dynamic LiquiDoc co
1125
1198
.Example liquidoc execution with a dynamic config file
1126
1199
[source,shell]
1127
1200
----
1128
-
bundle exec liquidoc -c _configs/init_topic.yml --configvar slug=some_c_slug-string --configvar title='Some Topic Title for Publication'
1201
+
bundle exec liquidoc -c _configs/init_topic.yml --var slug=some_c_slug-string --var title='Some Topic Title for Publication'
1129
1202
----
1130
1203
1131
1204
The example above commands an extraordinary LiquiDoc build routine.
@@ -1149,7 +1222,7 @@ The configuration file, `init_topic.yml`, creates topic-file stubs and schema-fi
1149
1222
----
1150
1223
1151
1224
As you can see, since this file has Liquid variables embedded in it, we must pass those variables during CLI execution in order for the build to work at all.
1152
-
This config file is parsed just like any standard parse action, though it uses the `--configvar` option to ingest environment variables, scoped as `vars.` in the template (remember, in this case _the config file itself is the template_).
1225
+
This config file is parsed just like any standard parse action, though it uses the `--var` option to ingest environment variables, scoped as `vars.` in the template (remember, in this case _the config file itself is the template_).
1153
1226
Parsing the configuration will essentially be the first act of the configured build routine, which will then run the parsed file, step by step.
1154
1227
1155
1228
.Example _parsed_ config file for topic-file stub generation
@@ -1303,6 +1376,12 @@ s| properties
1303
1376
| N/A
1304
1377
| Optional
1305
1378
|
1379
+
1380
+
s| search
1381
+
| N/A
1382
+
| N/A
1383
+
| Optional
1384
+
|
1306
1385
|===
1307
1386
1308
1387
pass:[*]The `output` setting is considered optional for render operations because static site generations target a directory set in the SSG's config file.
opts.on("--explicit","Log explicit step descriptions to console as build progresses. (Otherwise writes to file at #{@build_dir}/pre/config-explainer.adoc .)")do |n|
1160
+
opts.on("--explain","Log explicit step descriptions to console as build progresses. (Otherwise writes to file at #{@build_dir}/pre/config-explainer.adoc .)")do |n|
1119
1161
explainer_init("STDOUT")
1120
1162
@explainer.level=Logger::INFO
1121
1163
@logger.level=Logger::WARN# Suppress all those INFO-level messages
0 commit comments