How was the repo-1.dds.pizza remote archive created

[oraqlle]

I'm trying to test some things with DDS and I can't seem to replicate the repo (I am not a web developer and have little experience). Could I get an idea of how it was done. Thanks.

[vector-of-bool]

The repo-1.dds.pizza repository is generated by an Azure Pipelines CI job by using a Python program, which is available here. The dds-ports program downloads and manipulates remote Git repositories and source archives into dds-buildable forms, generates source distribution archives, and then imports them all into a repo, which is then uploaded to the public HTTP server. The majority of the complexity is written in Python, just using dds to manipulate the repository itself.

[oraqlle]

I've taken a look at dds-ports which is a very interesting (at least to me) CI workflow, I was more wondering though how the site as actually built and able to serve the static files and directories. As I said in the other discussion, I know very little about web development and wish to learn more.

[david-bakin]

With respect to creating a repository, you might consider looking into gitlab/github pages. Those are static websites automatically created (using any webdev tool/workflow/process) from a repo, every time there is a commit to the repo. I'm thinking of hosting a "personal" dds catalog/repo that way.

As far as webdev is concerned - static websites are fairly easy. Look for any one of a number of popular "SSG" ("static site generator") tools. Which typically also give you a way to incrementally move to more active websites. (I use Hugo, myself, but it isn't necessarily the absolute easiest to start with ... though it is fairly easy at that.)

[oraqlle]

Thanks for the confirmation. I'm doing the same thing (creating a static site to host my one packages)I've been using Zola which I think is like Hugo. It uses markdown to store information and then renders that using HTML. I think that a CLI could be created to take a Markdown file or folder with markdown and automatically create documentation pages if package vendors supply them (similar to how I think NPM works for Node. Open for correction.) allowing people to create their own fully documented packages. But not sure how this would look, haven't had the time due to school. @vector-of-bool what have you got planned in terms of a default repository site (if any yet)?

[david-bakin]

So basically in the ports directory there is a python script for each port (or group of related ports, like neo-*) that has two responsibilities:

1. Map port repo tags/releases to dds version numbers
2. Move files around in the port repo until they match dds (pitchfork) standards. Possibly adding new files, typically a header for configuration, if needed.

And they don't need to create the package.json5 file because in the single library/single package case dds will infer it on its own?