workflow

16523

1

ich stehe jetzt vor der herausforderung, diesen beitrag (project page as 2nd layer site in dcl multisite layout) so convenient wie möglich zu veröffentlichen.

options

graph TD

CR[create content] -->
dcl[in blog repo]
CR-->wd[in working repo]-->ml
dcl-->se[single post]
dcl-->ml[multilayer]
se-->fm[content format markdown, no python/R embedding or complex sites. restricted to jekyll render]
ml-->fmm[content may include complex page built from RMarkdown, Quarto or Python notebooks or any other framework]
o2[option 2]

Figure 1: “publishing process options diagram”

preliminary: setup, status quo

graph TD

s1[CONTENT]-->
dcl[jekyll site: dcl]
wd[working dir: spund-lx]
dcl-->p1[post display]-->
p2[2nd layer: project display]
wd-->p2
s1-->wd

Figure 2: “publishing process setup status quo”

goal: integrate new project page in blog

graph TD

s1[CONTENT: quarto page]-->
dcl[jekyll site: dcl: essais folder]
wd[working dir: GIT]-->wd2[spund-lx/lx-public/HA/DCL/pages]-->level1[complete quarto site folder including .qmd and quarto.yml]
level1-->ch[changes]-->r1[trigger rendering process]-->
git1[render via github actions]-->p2
r1-->srv1[render on target server]-->updcl[update DCL essais]-->p2
dcl-->p1[post entry]-->l1[link to 2nd layer: project page]-->p2
p2[2nd layer: project display]
ch-->rloc[docs rendered locally]-->p2
r1-->p2
wd-->csv[.csv metadata table of essais]-->ch-->chk1[is the project on DCL]-->pdcl1[yes]
s1-->wd
pdcl1-->r1
pdcl1-->rloc
chk1-->pdcl0[no]-->crp[create project page]-->crman[manually]
crp-->crcsv[on base of metadata.csv]-->csv-->pub1[publish]-->p2

Figure 3: “publishing process forward”

todo: next steps to project page

graph TD

crcsv[create .csv metadata table]-->
item[new project item]
wf[update render git workflow]-->wf1[to fire on changes in]-->csv[.csv metadata table]
crcsv-->csv-->item-->inc[includes]-->meta-->m1[render dir relative to working dir]
meta-->m2[tags]
meta-->m3[cats]

Figure 4: “publishing process next todo”

2

issues

there’s premises we have to clear off before developing to great extend

• if it will be (and thats not sure) possible at all to use github as storage and render platform that would deploy the pages to an FU server where the DCL page is hosted. there can be administrative concerns about providing or hosting the backend at github with everybody able to read the source code of the site. this should generally be no issue because there doesnt have to be stored any material exceeding what is displayed as html anyway thus accessible, but coming from this,

graph TD
    OP[options to avoid the github hosting service are:]
    TO[to render the pages completely on the contribuer device and deploy only html rendered pages to the restricted FU server -userpage level with no administrative user at the project level-]
    OP --> TO
    AF[affords the contribuer to install render services on device]
    TO --> AF
    CO[contribuer only pushes pages to site]
    TO --> CO
    ED[edited source stays on device]
    TO --> ED
    TO2[to use a page hosting server -or userpage level- which allows for admin tasks like installing basic render services -which here would be jekyll, ruby and quarto- and to maintaining these services]
    OP --> TO2
    CO2[contribuer needs to edit and push the markdown source which is rendered on the FU server apres]
    TO2 --> CO2
    AF2[affords admin poition for maintaing the packages server side]
    TO2 --> AF2

Figure 5: contribute options