Move to a dedicated domain

[Ainali]

We discussed in our last meeting moving this from the default GitHub pages URL to our own domain. Some of the ideas we had were:

• processcode.publiccode.net/software-procurment/
• process-code-software-procurement.publiccode.net
• software-procurement.processcode.net
• software-procurement.publiccode.net

[ericherman]

The processcode.publiccode.net/software-procurment/ option is complicated because we do not currently have a straight-forward way to deploy from a repository to a folder of a domain. This could be achieved in a few ways, for example, by creating a process-code git "super-project" which has folders like software-procurment as git sub-modules.

I'd suggest we choose one of the others which fit into our current tooling for the medium term, and if we decide to go with a more complex setup, we can redirect at that time.

[ericherman]

I favour one of:

• software-procurement.processcode.net
• software-procurement.publiccode.net

[ElenaFdR]

What are the arguments against putting all process codes in one repo, each in their own folder?

[ericherman]

I had an idea about how to create something with a different structure than the domain-per-repository, in order to get a structure with everything all one domain and still be able to manage and release the individual projects in their subdirectories separately.

If I understand the desire correctly, it would be ideal to get something along the lines of:

• how-to.example.org:/foo
• how-to.example.org:/bar
• how-to.example.org:/whiz
• how-to.example.org:/bang

While I don't see a good way to do this via GitHub's hosting, I see a maybe not-so-bad way.

It would be possible to create a "how-to" super-project with "foo", "bar", "whiz", and "bang" as git sub-modules.

The individual projects would create tags or releases, but not release directly to the hosting.

Instead, there would be a multi-phase release where, for instance, first there is a release on "foo", next a "git submodule update" is performed on "how-to", and then finally a release is made on "how-to" which contains the new content from "foo" and re-deploys all of the content together.

(There might be a better way still, as I might be over-looking something.)

[ericherman]

A possible variation on submodules, would be to have a super-project with a build that uses the gh-pages branch of each sub-project. The main advantage of this variation would be that each project would have independent builds, and the super-project would simply consume whatever each build outputs as its HTML, CSS, JavaScript, etc.
The super-project would "tool-agnostic" beyond basic git, and each sub-project could be built by Jekyll, Hugo, Docusaurus, etc. ... or even be just straight HTML+CSS+JS without a generator.

[ericherman]

I did a very basic test of this, and it is not hard to configure.

I created this simple Jekyll site that originally had the default GitHub deployment, and converted it to use a GitHub workflow to generate the HTML & pushes the results to the 'gh-pages' branch, which is documented in the readme:

• https://github.com/ericherman/test-deploy-migration-branch-to-workflow

And this site which consumes the gh-pages from the above repo, and uses it as a subdirectory within this repo's site:

• https://github.com/ericherman/test-deploy-super-project