Update deps, make faster to built

[shyim]

This vitepress project feels like super-duper duck-taped mess of things.

• Build logs are full of deprecations
• GitHub Actions takes +20 minutes to deploy of a STATIC page (not fault of runners)
• Messy setup with Symlinks and not properly documented where to put what also with different kind of versions

[bojanrajh]

Agree. We're currently running latest stable vitepress version, looking forward to migrating to v2 (in alpha 16) or alternative docs tech stack - IMO, zudoku seems promising as it also provides nice features for OpenAPI integration.

Building 3000 files for a static build takes some time (3 files/second = ~15 minutes). I experimented with partial builds in the past, but vitepress is just not made for that. Note that the build process actually takes a bit less time, if there're no deadlinks found, simply because it's build twice in such cases - https://github.com/shopware/developer-portal/blob/main/.github/workflows/checkout-test-build-deploy.yml#L140 .

Symlinks, well, we need to gather all the markdown from different repos somehow (and some even require source code to be present). The docs-cli is used in the Build and Healthcheck processes, and managing all those mountpoints from different repos can be managed with docs-cli manage and docs-cli cleanup commands - https://github.com/shopware/developer-portal/blob/main/QUICK-START.md . Some repos also provide the docs:X npm commands for local setup - https://github.com/shopware/docs/blob/main/package.json#L5 .

[shyim]

I believe most of the pipeline time is self-made problem. This all artifacts should be removed and the jobs should clone always the repo. It takes more time to Upload and Download the artifact than actually building it.

Also maybe make just two jobs: build+deploy / test. Both run parallel and dont depend on each other

[bojanrajh]

The optimized pipeline with 2 jobs (build&deploy) is actually used in the Healtcheck workflow in PRs in embedded repos. Still, it takes 20 minutes.

Main build takes 30 minutes. Looking at that, I'm not sure why uploading 2x150MB takes 8 minutes in total. Maybe we'll need to zip files upfront. The build then takes 15 minutes + 2 minutes to test + 2 minutes to deploy + 1 minute to update knowledge-index.

It is crucial to run the clone action once (and create artifact) as one of the repositories could be changed in the meanwhile. The same datasource needs to be used by the dev and prod builds (there were differences in the past between them) and for the knowledge-index (AI Copilot Q&A, synced only after the prod deployment was made). Similarly, because of data consistency and to avoid building the project twice, we run tests on the actual build and the same build is later deployed to Vercel.

Now, yes, this could all run in a single job, but there were numerous times when those artifacts and separated jobs actually helped us restarting only a specific job, let that be issues with git clone, (p)pnm install, apt, vercel or anything else that's part of the pipeline.

I would also argue to keep the deployment step dependant on the test step (which takes 2 minutes). And we can't run build&test in paralel as we need to test the build itself. We don't test many things there, just the basic things for all the embedded repos, but it makes me sleep better. 👯 Core functions (theme and cli) are tested in the theme repo already.