Add Section for Docs regarding SCS Developers

dev-docs/index.md

@@ -0,0 +1,5 @@
+# Documentation for SCS Developers
+
+Welcome to the Dev Docs. This section is primarily for SCS Developers and will contain documentation regarding the Development and Architecture of the Sovereign Cloud Stack and its components. You will find documents, explanations and guides regarding the tooling necessary for the development of SCS.
+
+If you want to contribute you can reach out to us via our [Matrix Channel](https://matrix.to/#/!TiDqlLmEUaXqTemaLc:matrix.org?via=matrix.org).

operations/iam/openstack-federation-via-oidc.md → dev-docs/operations/iam/openstack-federation-via-oidc.md

@@ -20,9 +20,9 @@ The following sections describe the setup.
 To allow SCS to consume identities managed in external IAM solutions,
 federation protocols like OpenID Connect or SAML can be used.
 Keystone currently makes use of third party apache modules like
-[mod\_auth\_openidc](https://github.com/OpenIDC/mod_auth_openidc),
-[mod\_oauth2](https://github.com/OpenIDC/mod_oauth2) and
-[mod\_auth\_mellon](https://github.com/UNINETT/mod_auth_mellon) to delegate
+[mod_auth_openidc](https://github.com/OpenIDC/mod_auth_openidc),
+[mod_oauth2](https://github.com/OpenIDC/mod_oauth2) and
+[mod_auth_mellon](https://github.com/UNINETT/mod_auth_mellon) to delegate
 authentication to a SSO IdP (i.e. SAML IdP or OpenID Connect provider).
 
 In OpenStack the apache modules are configured using the

operations/operations/zuul-ci-cd-quickstart-user-guide.md → dev-docs/operations/operations/zuul-ci-cd-quickstart-user-guide.md

@@ -115,56 +115,56 @@ Pipelines available in SCS Zuul:
 
 #### 1. check
 
-* event driven pipeline
-* runs if a pull request is created, changed or reopened
-* re-runs if a comment contains `recheck`
+- event driven pipeline
+- runs if a pull request is created, changed or reopened
+- re-runs if a comment contains `recheck`
 
 #### 2. gate
 
-* event driven pipeline
-* trigger events: pull_request_review, pull_request, check_run
+- event driven pipeline
+- trigger events: pull_request_review, pull_request, check_run
 
 #### 3. post
 
-* event driven pipeline
-* trigger event: post
+- event driven pipeline
+- trigger event: post
 
 #### 4. tag
 
-* event driven pipeline
-* trigger event: push
+- event driven pipeline
+- trigger event: push
 
 #### 5. e2e-test
 
-* event driven pipeline
-* trigger event: pull_request
+- event driven pipeline
+- trigger event: pull_request
 
 #### 6. e2e-quick-test
 
-* event driven pipeline
-* trigger event: pull_request
+- event driven pipeline
+- trigger event: pull_request
 
 #### 7. unlabel-on-update-e2e-test
 
-* event driven pipeline
-* trigger event: pull_request
+- event driven pipeline
+- trigger event: pull_request
 
 #### 8. unlabel-on-update-e2e-quick-test
 
-* event driven pipeline
-* trigger event: pull_request
+- event driven pipeline
+- trigger event: pull_request
 
 #### 9. periodic-hourly
 
-* time based pipeline that runs every hour
+- time based pipeline that runs every hour
 
 #### 10. periodic-daily
 
-* time based pipeline that runs every day at 3 o'clock am.
+- time based pipeline that runs every day at 3 o'clock am.
 
 #### 11. compliance_check
 
-* time based pipeline that runs every 15 minutes
+- time based pipeline that runs every 15 minutes
 
 If you want to know more about pipelines: [See official documentation](https://zuul-ci.org/docs/zuul/latest/config/pipeline.html)
 
@@ -200,7 +200,6 @@ First have a look on a basic job example:
       nodes:
         - name: ubuntu-jammy
           label: ubuntu-jammy
-
 ```
 
 Each job needs a name that has to be unique within the whole tenant.
@@ -319,7 +318,6 @@ For a basic but working example the following content may be written into a `zuu
 
 ```yaml
 # zuul.yaml content
-
 ---
 - secret:
     name: mySecret
@@ -331,8 +329,8 @@ For a basic but working example the following content may be written into a `zuu
     name: myFirstTestJob
     parent: base
     secrets:
-     - name: secretName # The name of the secret that is used within "playbooks/testPlaybook.yaml"
-       secret: mySecret
+      - name: secretName # The name of the secret that is used within "playbooks/testPlaybook.yaml"
+        secret: mySecret
     run: playbooks/testPlaybook.yaml
 
 - project:
@@ -352,7 +350,6 @@ Example playbook:
 
 ```yaml
 # playbooks/testPlaybook.yaml content
-
 ---
 - hosts: all
   tasks:

docusaurus.config.js

@@ -71,6 +71,16 @@ const config = {
         // ... other options
       },
     ],
+    [
+      "@docusaurus/plugin-content-docs",
+      {
+        id: "dev-docs",
+        path: "dev-docs",
+        routeBasePath: "dev-docs",
+        sidebarPath: require.resolve("./sidebarsDevDocs.js"),
+        // ... other options
+      },
+    ],
     [
       "@docusaurus/plugin-content-docs",
       {
@@ -102,8 +112,9 @@ const config = {
         },
         items: [
           //   { to: '/blog', label: 'Blog', position: 'left' },
-          { to: "/docs", label: "Docs", position: "left" },
           { to: "/standards", label: "Standards", position: "left" },
+          { to: "/docs", label: "For Operators", position: "left" },
+          { to: "/dev-docs", label: "For Developers", position: "left" },
           { to: "/community", label: "Community", position: "left" },
           { to: "/docs/faq", label: "FAQ", position: "left" },
           {
@@ -178,8 +189,8 @@ const config = {
       // @ts-ignore
       ({
         hashed: true,
-        docsDir: ["docs", "community", "standards"],
-        docsRouteBasePath: ["docs", "community", "standards"],
+        docsDir: ["docs", "community", "standards", "dev-docs"],
+        docsRouteBasePath: ["docs", "community", "standards", "dev-docs"],
       }),
     ],
   ],

sidebarsDevDocs.js

@@ -0,0 +1,13 @@
+// @ts-check
+
+/** @type {import('@docusaurus/plugin-content-docs').SidebarsConfig} */
+const sidebars = {
+  devDocs: [
+    {
+      type: "autogenerated",
+      dirName: ".", // '.' means the current docs folder
+    },
+  ],
+};
+
+module.exports = sidebars;