Reuse existing health-analyzer stack components to deliver on this?

[janhalen]

@zorp: I Propose that we stop waiting, forget about manually trying to solve this inside the os2 secreatariat and instead raise a sufficient budget to deliver on this.

My idea is to reuse the stack designed for the project-health-analyzer and find a hosting and operations partner to run this...

Heres is a rough list of technical tasks that i recommend you raise a returning budget for:

Checklist for Implementing a Digitally Sovereign Open Source Code Forge and CI/CD Stack

1. Set Up a Contract with a Digitally Sovereign Hosting Partner and an Operations Partner

• Action Items:
  • Identify and select a hosting partner that meets digital sovereignty requirements.
  • Identify and select an operations partner to manage the infrastructure.
  • Define the scope of services, including hosting, operations, and support.
  • Include provisions for data sovereignty, compliance with relevant regulations, and service level agreements (SLAs).
  • Ensure that the contracts clearly outline responsibilities, timelines, and deliverables.

2. Set Up a Contract with the Partners Mentioned in Point 1 to Implement a Digitally Sovereign Open Source Code Forge, CI/CD Stack, and Static Page Hosting

• Action Items:
  • Clearly outline the requirements for the code forge, CI/CD stack, and static page hosting.
  • Include timelines, milestones, and deliverables to track progress and ensure accountability.
  • Ensure that the contracts include provisions for data sovereignty, compliance, and security.

3. Reuse and Combine the Elements from the Project-Health-Analyzer Stack to Build a Solution That Collects Data from All the OS2 Solutions Source Code Repos

• Action Items:
  • Document the existing components and workflows from the project-health-analyzer stack.
  • Plan for any necessary modifications or extensions to adapt the stack to your specific needs.
  • Ensure that the solution can collect data from all relevant source code repositories.

4. Convert These Collected Data and Make Both a Static Serving of the Products Data and Optionally a Simple “Catalogue” Front Page Running on the Forge's Standard Static Site Hosting

• Action Items:
  • Define the data transformation and conversion processes to ensure accurate and efficient conversion.
  • Consider the design and user experience of the static serving page and the optional catalogue front page.
  • Ensure that the static pages are user-friendly and informative.

5. Ready to Submit Our “Catalogue” URL to the EU Catalogue Crawler

• Action Items:
  • Ensure that the catalogue URL is publicly accessible.
  • Format the data according to the EU Catalogue's requirements.
  • Test the submission process to ensure that the crawler can successfully access and index the data.

There is not included all the organisational tasks for creating and maintaining the publiccode.yml files in all the repos...

[janhalen]

---

🇪🇺 Investment in EU Catalog Compatibility

This implementation proposal outlines a three-step plan for adopting the open-source Gaia-X standards to ensure our projects become certified, trusted Digital Public Goods ready for immediate inclusion in the EU Federated Catalog.

This proposal is a single, future-proof investment. By building the necessary trusted plumbing now, we eliminate the need for costly, disruptive retrofitting of security, compliance, and identity features later, thereby maximizing the public value and widespread adoption of our projects across Europe.

Deliverable	Strategic Goal & Benefit (Future-Proofing)	Key Investment Term
0. Project Initiation & Assessment	Success Blueprint & Risk Mitigation: Define the precise technical scope, select the required EU Trust Label Level (e.g., Level 2), and conduct the necessary internal readiness assessment. This ensures all subsequent phases are budgeted and scheduled correctly.	Success Blueprint
1. Metadata Foundation	Visibility & Searchability: We format our project details using the common, required EU standard now. This makes our software instantly searchable and compatible with the EU Catalog, guaranteeing Zero Data Rework later.	Zero Data Rework
2. Cryptographic Identity	Unbreakable Trust & Origin: We embed digital signatures directly into the release process. This gives us digital sovereignty—proving our Foundation is the source—meaning we never have to add complex security features later.	No Retrofit for Crypto
3. Verified Compliance	Mandatory Access & Trust Badge: We gain the official Gaia-X Trust Badge (the mandatory EU compliance stamp). This is the only way to get listed in the EU Catalog, securing our market position.	Guaranteed Catalog Access

---

Next Steps and Acceptance Criteria

Phase Acceptance Criteria (High-Level):

1. Phase 0 Completion: The technical assessment and delivery plan for all subsequent phases is complete and approved.
2. Phase 1 Completion: The public description URL is successfully deployed and accessible.
3. Phase 2 Completion: The automation pipeline successfully generates a valid, self-signed, trusted file for the project.
4. Phase 3 Completion: The official EU verification body returns a signed, valid Trust Credential for the project, making it ready for the EU Catalog.

Upon acceptance of this approval, a technical assessment and delivery plan will be made for each phase, learning from the previous phase.

---