Create build-deploy-staging.yml

[HassanAkbar]

Adding workflow for staging

[ronaldtse]

@HassanAkbar looks like the deployment shows 404...?

[HassanAkbar]

@ronaldtse I was testing to deploy the staging branch but it didn't work so I rerun the code to deploy the main branch.

[ReesePlews]

hello @HassanAkbar sorry to cause problems with the request for the staging area deployment at first. i am happy to check the updates when they are ready. please send me the URL and i will have a look. thank you.

[HassanAkbar]

@ReesePlews Thanks I am working on it. Will let know as soon as its ready for verification.

@ronaldtse I've looked into the subfolder deployment for fontist and from what I understand this was achieved by deploying fontist/formulas and fontist/fontist repos that by default will get deployed to /formula and /fontist respectively due to github pages https://<org>.github.io/<repo>/ pages site structure for separate repos, and then the root site (fontist/fontist.github.io) is deployed which has links to the 2 already deployed sites.

I think, it is not possible to deploy to a subpath from the same repo.
We would need a separate repo that we can deploy to a different path i.e geolexica/staging to deploy to isotc211.geolexica.org/staging path.
Should we go down this path?

[ronaldtse]

@HassanAkbar yes let’s create a new repo for staging so we can deploy to the sub path. Thanks!

[HassanAkbar]

@ronaldtse I've tried testing this using a separate directory by forking this here and the issue is that the URLs will stop working if we deploy it to a sub directory because:

• We have static urls defined in the front matter inside the page, e.g _pages/about.adoc and there is no option in Jekyll to use variables inside the front matter.
• Some of the pages are generated from the Jekyll-geolexica

If we try to somehow fix the URLs to work in both environments then it will be a tricky & un-needed effort for adding/maintaining an environment. We will not only have to change in this repo but also in jekyll-geolexica repo.

1. A maintainable/better solution can be to add a custom domain to the staging repo like isotc211-staging.geolexica.org.
2. If we want to stay away from Custom Domains and totally rely on Github Pages, we can create a new Github org: Geolexica-Staging & host the staging on geolexica-staging.github.io.

This will remove the project name from the URL and everything will work as expected. What do you think?

[ronaldtse]

• We have static urls defined in the front matter inside the page, e.g _pages/about.adoc and there is no option in Jekyll to use variables inside the front matter.
• Some of the pages are generated from the Jekyll-geolexica

Can we relax these?

[HassanAkbar]

@ReesePlews you can test the concepts here https://geolexica-staging.github.io.

@ronaldtse I didn't want to block the staging testing, so for now I have created a new repo with the staging code and deployed it. If we want to keep this behavior then let me know where to transfer ownership of this repo and if we want to go with custom domain then I can move the workflow to the provided repo. Let me know what you think about this.

[HassanAkbar]

• We have static urls defined in the front matter inside the page, e.g _pages/about.adoc and there is no option in Jekyll to use variables inside the front matter.
• Some of the pages are generated from the Jekyll-geolexica

Can we relax these?

@ronaldtse Just saw your response now, I will have to look into that. I'm not sure if we can do something about the front matter using configuration. I'll check on that and let you know.

[ReesePlews]

hello @HassanAkbar thank you very much for getting the staging site working. i will be checking it more.

i have looked briefly and noticed the following items...

1. the math formulae and styles do not seem to be recognizing the stem:[ ] syntax. is this an internal issue or a browser issue meaning something i need to do to support the math script? this is important as i am updating all of my internal spreadsheet files to support this type of math syntax. i want to make sure it can be used.

as rendered on FFox for Windows (current release 123.0.1)

2. the "Find a concept" does not seem to be working unless the "valid" check box is un-checked.

3. a style issue: we can deal with this later, but the alternating lines on the list of matched terms will need to be adjusted or removed as the color behind the gray bands are not easily visible.

if you could check into 1 and 2 that would be great. 3 can wait, not a priority.

thank you very much.

[HassanAkbar]

hello @HassanAkbar thank you very much for getting the staging site working. i will be checking it more.

i have looked briefly and noticed the following items...

1. the math formulae and styles do not seem to be recognizing the stem:[ ] syntax. is this an internal issue or a browser issue meaning something i need to do to support the math script? this is important as i am updating all of my internal spreadsheet files to support this type of math syntax. i want to make sure it can be used.

as rendered on FFox for Windows (current release 123.0.1)

2. the "Find a concept" does not seem to be working unless the "valid" check box is un-checked.
3. a style issue: we can deal with this later, but the alternating lines on the list of matched terms will need to be adjusted or removed as the color behind the gray bands are not easily visible.

if you could check into 1 and 2 that would be great. 3 can wait, not a priority.

thank you very much.

Thanks @ReesePlews for pointing this out. I am already looking into this.

[ReesePlews]

thank you @HassanAkbar, i appreciate your work on this. @ronaldtse and i have discussed the math syntax a lot. i am sure it will look very nice when implemented. thanks for your continued work!

[HassanAkbar]

@ronaldtse Currently, there is no support for stem syntax in geolexica sites. The math was being handled by MathJax as mentioned in issue #133.

Should we just convert the stem:[some math] to MathJax syntax while generating the site or should I use plurimath to convert stem to MathML and render that?

[ronaldtse]

@HassanAkbar Personally I prefer using plurimath because we know the results are consistent.

There are a few ways to integrate:

1. Create a jekyll-plurimath gem that extends jekyll-asciidoc, so the text is run through Plurimath Ruby to convert stem:[...] blocks into MathML inside the jekyll-asciidoc-produced HTML. Then use MathJax to render the MathML.
2. Use Plurimath JS to parse stem:[...] in the HTML page and convert them into MathML. Then use MathJax to render the MathML.

What do you think is better?

[HassanAkbar]

@ronaldtse There are pros and cons to both approaches

1. Making a ruby gem will increase the build time but the generated pages will be faster as there is no precessing at the front end. And with this approach we won't be able to build the site if some math equations are crashing.
2. Using JS will increase the load time of the pages which have math because it needs to convert it every time the page loads (the time it takes will be very small may be a few mili seconds depending on the math included on the page), also with this approach if a math formula is broken we won't be able to catch it until that page is opened.

I think making a ruby gem here is better. what do you suggest?

[ronaldtse]

@HassanAkbar I agree with the analysis. In any case, it is possible to skip the broken formulas during processing.

[HassanAkbar]

@ronaldtse I am working on converting the math using Plurimath.

Create a jekyll-plurimath gem that extends jekyll-asciidoc

You mentioned that we need to create a gem that extends from jekyll-asciidoc but after some research I found that the concepts in Jekyll-geolexica are instance of PageWithoutAFile, and I think they are not currently being processed by Jekyll-asciidoc.

So, I've added a post_render hook for pages to convert the stem:[...] tag in the generated content.

I just want to confirm, do we move this hook to a new gem or should I add this to the already present hooks in Jekyll-geolexica?

[ronaldtse]

@HassanAkbar keeping in the current gem is fine. Please help merge the finished PRs. Thanks!

[ronaldtse]

@HassanAkbar please also release any gems as necessary, thanks.

[ReesePlews]

hello @HassanAkbar and @ronaldtse i know the content at the staging link ( https://geolexica-staging.github.io ) is still under development but i am noticing some other issues that are different from the current geolexica site ( https://isotc211.geolexica.org ) where should i report those issues, can i use this repo or a different one?

also, just to confirm that the there will be no change to the content and math encoding style as currently shown on the staging site, is that correct?

thanks for all the work on this Hassan!

[ronaldtse]

@ReesePlews please report all staging issues to this repo. There is no change to the layouts. Thanks!

[ronaldtse]

@HassanAkbar can this be now merged? Thanks.

[HassanAkbar]

@ronaldtse This needs to be updated now, we have moved the staging site to the isotc211-staging repo so in this PR I'll update the workflow to despatch a task to isotc211-staging when something is merged into staging here.

[ronaldtse]

@HassanAkbar okay, just merge whenever appropriate. Thanks.

[ronaldtse]

@HassanAkbar is this still needed? What's going on?

[HassanAkbar]

@ronaldtse this is not needed, We need to write a different workflow that will dispatch another workflow in the staging repo.

I'll finalize this right after finalizing Lutaml::Model test cases.