Use 'process_description module' as Process (#1192)

* Add 'release' version
* Resolved links to Process Description
* Adapt workflow to new target
* Increase versions

Co-authored-by: markus.schu <[email protected]>

Author: MaximilianSoerenPollak

.github/workflows/docs.yml

@@ -55,7 +55,7 @@ jobs:
         run: sudo apt update && sudo apt install -y graphviz
       - name: Build documentation
         run: |
-          bazel build //docs:github_pages && cp bazel-bin/docs/github_pages.tar .
+          bazel build //docs:github_pages__release && cp bazel-bin/docs/github_pages__release.tar .
         # ------------------------------------------------------------------------------
         # Generate a unique artifact name to ensure proper tracking in all scenarios
         # ------------------------------------------------------------------------------
@@ -69,7 +69,7 @@ jobs:
         uses: actions/[email protected]
         with:
           name: github-pages-${{ github.event.pull_request.head.sha || github.sha }}
-          path: github_pages.tar
+          path: github_pages__release.tar
           retention-days: 1
           if-no-files-found: error
 
@@ -106,7 +106,7 @@ jobs:
           name: github-pages-${{ github.event.pull_request.head.sha || github.sha }}
 
       - name: Untar documentation artifact
-        run: mkdir -p extracted_docs && tar -xf github_pages.tar -C extracted_docs
+        run: mkdir -p extracted_docs && tar -xf github_pages__release.tar -C extracted_docs
 
       - name: Deploy 🚀
         id: pages-deployment

MODULE.bazel

@@ -65,15 +65,15 @@ bazel_dep(name = "aspect_rules_lint", version = "1.4.2")
 # Java version
 #
 ###############################################################################
-bazel_dep(name = "rules_java", version = "8.6.3")
+bazel_dep(name = "rules_java", version = "8.11.0")
 
 ###############################################################################
 #
 # Misc. dependency
 #
 ###############################################################################
 
-bazel_dep(name = "score_python_basics", version = "0.3.1")
+bazel_dep(name = "score_python_basics", version = "0.3.2")
 
 ###############################################################################
 #
@@ -90,4 +90,5 @@ bazel_dep(name = "score_cr_checker", version = "0.2.2")
 bazel_dep(name = "score_starpls_lsp", version = "0.1.0")
 # Checker rule for CopyRight checks/fixs
 
-bazel_dep(name = "score_docs_as_code", version = "0.2.6")
+bazel_dep(name = "score_docs_as_code", version = "0.3.2")
+bazel_dep(name = "score_process", version = "0.2.0")

docs/BUILD

@@ -25,7 +25,25 @@ docs(
     conf_dir = "docs",
     docs_targets = [
         {
-            "suffix": "",  # local without external needs
+            "suffix": "latest",  # latest main branch documentation build
+            "external_needs_info": [
+                {
+                    "base_url": "https://eclipse-score.github.io/process_description/main",
+                    "json_url": "https://eclipse-score.github.io/process_description/main/needs.json",
+                    "id_prefix": "process_",
+                },
+            ],
+        },
+        {
+            "suffix": "release",  # latest main branch documentation build
+            "target": ["@score_process//process:docs_needs_latest"],
+            "external_needs_info": [
+                {
+                    "base_url": "https://eclipse-score.github.io/process_description/main",
+                    "json_path": "/score_process~/process/docs_needs_latest/_build/needs/needs.json",
+                    "id_prefix": "process_",
+                },
+            ],
         },
     ],
     source_dir = "docs",

docs/contribute/contribution_request/feature_request.rst

@@ -25,7 +25,7 @@ This Guideline is based on or references following documents:
 
 * :ref:`Contribution Guideline <contribute_contribution_guideline>`
 * :ref:`Change Management Plan <change_mgmt_plan>`
-* :ref:`Feature Template <chm_feature_templates>`
+* :need:`Feature Template <PROCESS_gd_temp__change__feature_request>`
 
 Creation of Feature Request
 ================================
@@ -79,7 +79,7 @@ First of all, change the status of *Feature Request* to "in Progress" state.
 *Feature Requests*, that stay in the status "Draft" longer as 4 weeks, will be deleted.
 Afterwards create a PR with your proposal in the `/docs/features <https://github.com/eclipse-score/score/tree/main/docs/features>`_ score repository.
 There you will find currently existing features as subfolders. Please choose the one that fits your *feature request* the most or
-create a new subfolder, if none of existing feature match your *feature request*. Please take care, that the PR follows the :ref:`Feature Template <chm_feature_templates>`.
+create a new subfolder, if none of existing feature match your *feature request*. Please take care, that the PR follows the :need:`Feature Template <PROCESS_gd_temp__change__feature_request>`.
 You should try to put as much information as possible, as a good exhaustive description is a prerequisite for *feature request* to be accepted.
 
 It is important to understand, that *feature request* consists of an GitHub Issue, that is used to track organizational information and

docs/contribute/contribution_request/index.rst

@@ -25,7 +25,7 @@ How to Contribute?
 How we Work
 ===========
 
-At S-CORE, we believe that every contribution makes our platform stronger. Whether you're a seasoned developer or just starting out in open source, your ideas and work are warmly welcomed. We follow a structured yet flexible process rooted in our change management principles and overall lifecycle concept. For more details on our processes, feel free to explore our :ref:`general_concepts_lifecycle` and the :ref:`change_management`. And if you want to dive right into contributing, check out :ref:`what_is_a_pr` and :ref:`what_is_a_github_issue`.
+At S-CORE, we believe that every contribution makes our platform stronger. Whether you're a seasoned developer or just starting out in open source, your ideas and work are warmly welcomed. We follow a structured yet flexible process rooted in our change management principles and overall lifecycle concept. For more details on our processes, feel free to explore our `Life Cycle Concept <https://eclipse-score.github.io/process_description/main/general_concepts/score_lifecycle_concept.html>`_ and the :need:`doc__platform_change_management_plan`. And if you want to dive right into contributing, check out :ref:`what_is_a_pr` and :ref:`what_is_a_github_issue`.
 
 Feature Requests: Our Shared Roadmap
 ------------------------------------
@@ -95,9 +95,9 @@ A Pull Request (**PR**) is the **ONLY** way to contribute **CODE** to the *S-COR
 
 The figure below shows a simplified workflow for a PR.
 
-* The contributor (:need:`Contributor <rl__contributor>`) starts by creating a PR:  `Creating a Pull Request (Github Docs) <https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request>`_.
+* The contributor (:need:`Contributor <PROCESS_rl__contributor>`) starts by creating a PR:  `Creating a Pull Request (Github Docs) <https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request>`_.
 * Required reviewers will be automatically assigned based on the contributed content (via CODEOWNERS).
-* If the content fullfils the review and acceptance criteria, a committer (:need:`Committer <rl__committer>`) will approve the *PR* and thus it can be merged.
+* If the content fullfils the review and acceptance criteria, a committer (:need:`Committer <PROCESS_rl__committer>`) will approve the *PR* and thus it can be merged.
 
 .. figure:: _assets/score_contribution_request_simple.drawio.svg
   :width: 600
@@ -108,7 +108,7 @@ The figure below shows a simplified workflow for a PR.
 
 Content in general may contain features, requirements, architectural designs, modules, components, detailed designs, implementations and source code, tests, process descriptions, any documentations, guidelines, tutorials, tools, or infrastructure topics and more of the *S-CORE* project. In case of doubt or for any other input we strongly encourage to open a *GitHub Issue* (:need:`doc__issue_guideline`) first.
 
-The *PR* should provide all required information of the new or changed content. Therefore the *S-CORE* project provides content specific templates, which the contributor (:need:`Contributor <rl__contributor>`) must use for his *PR* (ToDo link here to the templates overview). Templates may be *PR* templates, *GitHub Issue* templates and also additional document or work product templates.
+The *PR* should provide all required information of the new or changed content. Therefore the *S-CORE* project provides content specific templates, which the contributor (:need:`Contributor <PROCESS_rl__contributor>`) must use for his *PR* (ToDo link here to the templates overview). Templates may be *PR* templates, *GitHub Issue* templates and also additional document or work product templates.
 
 The content of any *PR* is the commit content and the description as well as the comments given in GitHub and is kept in a versioned repository, their revision history is the historical record of the PR.
 
@@ -132,23 +132,23 @@ The figure below gives an overview about all the possible steps for a *PR* until
 Create a PR
 -----------
 
-The contributor (:need:`Contributor <rl__contributor>`) creates a PR.
+The contributor (:need:`Contributor <PROCESS_rl__contributor>`) creates a PR.
 
-Reviewers will be automatically assigned (:need:`Committer <rl__committer>`) based on the contributed content (ruleset as defined by the committers). In addition several checks for the contributed content (ToDo: Link to the description of the checks) will be started.
+Reviewers will be automatically assigned (:need:`Committer <PROCESS_rl__committer>`) based on the contributed content (ruleset as defined by the committers). In addition several checks for the contributed content (ToDo: Link to the description of the checks) will be started.
 
 Review and merge a PR
 ---------------------
 
-A *PR* is reviewed with all content that adds/modifies it. As long as a *PR* requires further work by the contributor (:need:`Contributor <rl__contributor>`), the *PR* is not approved and thus not merged and further changes are requested. Once the contributor (:need:`Contributor <rl__contributor>`) considers all review comments as resolved, :need:`Contributor <rl__contributor>` can re-request a review. The committer (:need:`Committer <rl__committer>`) reviews the *PR* content according the *S-CORE* review and acceptance criteria (ToDo link here to the criteria).
-Further the contributor (:need:`Contributor <rl__contributor>`) must resolve found issues from the automated checks, if they do not pass.
+A *PR* is reviewed with all content that adds/modifies it. As long as a *PR* requires further work by the contributor (:need:`Contributor <PROCESS_rl__contributor>`), the *PR* is not approved and thus not merged and further changes are requested. Once the contributor (:need:`Contributor <PROCESS_rl__contributor>`) considers all review comments as resolved, :need:`Contributor <PROCESS_rl__contributor>` can re-request a review. The committer (:need:`Committer <PROCESS_rl__committer>`) reviews the *PR* content according the *S-CORE* review and acceptance criteria (ToDo link here to the criteria).
+Further the contributor (:need:`Contributor <PROCESS_rl__contributor>`) must resolve found issues from the automated checks, if they do not pass.
 
-As long as the *PR* does not meet the defined criteria and the checks does not pass, it will not be approved. If it does not follow the required templates, based on the provided content or the templates are not filled out properly, the committer as reviewer (:need:`Committer <rl__committer>`) will place the *PR* to the "Draft" state.
+As long as the *PR* does not meet the defined criteria and the checks does not pass, it will not be approved. If it does not follow the required templates, based on the provided content or the templates are not filled out properly, the committer as reviewer (:need:`Committer <PROCESS_rl__committer>`) will place the *PR* to the "Draft" state.
 
-It is then the responsibility of the contributor (:need:`Contributor <rl__contributor>`) to add the missing information and to re-start the contribution by placing the *PR* back for review.
+It is then the responsibility of the contributor (:need:`Contributor <PROCESS_rl__contributor>`) to add the missing information and to re-start the contribution by placing the *PR* back for review.
 
 To change from "Draft" to "Open" see `Changing the stage of a pull request (Github Docs) <https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/changing-the-stage-of-a-pull-request>`_.
 
-At any point the contributor (:need:`Contributor <rl__contributor>`) may decide not to continue with the PR, then the contributor (:need:`Contributor <rl__contributor>`) just closes the PR.
+At any point the contributor (:need:`Contributor <PROCESS_rl__contributor>`) may decide not to continue with the PR, then the contributor (:need:`Contributor <PROCESS_rl__contributor>`) just closes the PR.
 
 .. _what_is_a_github_issue:
 

docs/contribute/development/development_environment.rst

@@ -16,7 +16,7 @@
    :id: doc__develop_environment
    :status: valid
    :safety: ASIL_B
-   :realizes: wp__sw_development_plan
+   :realizes: PROCESS_wp__sw_development_plan
 
 .. _setting_up_dev_env: