QG 4 checks Release 3.2

[SebastianBezold]

QG checks

Please keep this issue open until QG 4 is concluded and will be managed by the Issue Creator!
We will inform you about finding and proposals in separated issues, this issue here is for the Overview of the Checks!

Product Name:
Product Owner:
Dev SPOC:
Helm Chart Version:
App Version:

Check of Tractus-X Release Guidelines

This QG 4 Check is depending on the mandatory information from our current Release Guidelines.

TRG 1 Documentation

• TRG 1.01 appropriate README.md
• TRG 1.02 appropriate INSTALL.md
• TRG 1.03 appropriate CHANGELOG.md

TRG 2 Git

• TRG 2.01 default branch is named main

• TRG 2.03 repository structure

  Checks within TRG 2.03

  • TRG 2.03 /docs directory contains detailed product related documentation for the Tractus-X product
  • TRG 2.03 /charts directory contains the Helm chart for the Tractus-X product IF available
  • TRG 2.03 AUTHORS.md file (optional) (TRG 2.03)
  • TRG 2.03 CODE_OF_CONDUCT.md file (TRG 2.03)
  • TRG 2.03 CONTRIBUTING.md file (TRG 2.03)
  • TRG 2.03 DEPENDENCIES file(s) with up to date content (Dash tool generated) (TRG 2.03)
  • TRG 2.03 LICENSE file (TRG 2.03)
  • TRG 2.03 NOTICE.md file (TRG 2.03)
  • TRG 2.03 SECURITY.md file (TRG 2.03)

• TRG 2.04 Leading product repository

  Checks within TRG 2.04

  • TRG 2.04 repository name must be productname without prefix or suffix
  • TRG 2.04 should contain the release
  • TRG 2.04 references/urls to the product's other repositories
  • TRG 2.04 might contain product helm chart(s)
  • TRG 2.04 README.md: contains the urls for the underlying applications

• TRG 2.05 .tractusx metafile in a proper format

TRG 3 Kubernetes

• TRG 3.02 PersistentVolume and PersistentVolumeClaim is used when needed

TRG 4 Container

• TRG 4.01 semantic versioning and tagging

• TRG 4.02 top level README.md file, that contains information about the used base image

• TRG 4.03 Image has USER command and Non Root Container

  Checks within TRG 4.03

  • TRG 4.03 deployment.yaml has runAsUser and allowPrivilegeEscalation: false properly set

• TRG 4.05 released image must be place DockerHub as mandatory container registry; remove GHCR references

• TRG 4.06 Notice File for DockerHub has all necessary information

  Checks within TRG 4.06

  • TRG 4.06 Link to the source of your base image (Container registry and GitHub if available)
  • TRG 4.06 Link to your product image on DockerHub
  • TRG 4.06 Link to your repository on GitHub
  • TRG 4.06 Direct link to the Dockerfile used to build your image
  • TRG 4.06 Link to LICENCE file in your repo as Project License (make clear, that this is the PROJECT licence, not an image license

TRG 5 Helm

• TRG 5.01 Helm chart must be released

  Checks within TRG 5.01

  • TRG 5.01 appropriate semantic versioning for version and appVersion has to be used in Chart.yaml
  • TRG 5.01 must not contain any environment specific values-xyz.yaml
  • TRG 5.01 values.yaml file must contain proper default values/placeholders
  • TRG 5.01 No hostname provided for ingress
  • TRG 5.01 Ingress is disabled
  • TRG 5.01 No references to any secret engine service (e.g.: Hashicorp Vault)
  • TRG 5.01 Dependencies should be prefixed with the nameOverride and/or fullnameOverride properties
  • TRG 5.01 Image tag is set to the Chart.yaml appVersion property
  • TRG 5.01 must be deployable to any environment without overwriting default values with a simple helm install command
  • TRG 5.01 dependencies have to be declared in Chart.yaml NOT requirements.yml

• TRG 5.02 Helm chart location in /charts directory and correct structure

  Checks within TRG 5.02

  • TRG 5.02 each file must contain the Apache 2.0 Licence
  • TRG 5.02 latest tag is not used in helm chart be default

  charts/ 
      chartNameA/
        Chart.yaml
        ... 
      chartNameB/
        Chart.yaml
        ...
  AUTHORS.md 
  DEPENDENCIES.md 
  LICENCE 
  README.md 

• TRG 5.04 CPU and memory limits and requests are properly set

• TRG 5.06 application must be configurable through the Helm chart

• TRG 5.07 dependencies are present in the Chart.yaml they are properly configured

• TRG 5.08 a product has a single deployable helm chart that contains all components

  Checks within TRG 5.08

  • TRG 5.08 name of the Chart should be just the product-name without prefix or suffix
  • TRG 5.08 values file should contain all available variables (even from subcharts) with default values and comments about what they do
  • TRG 5.08 helm install command should successfully install the chart to any supported Kubernetes version cluster (without overwriting default values)
  • TRG 5.08 helm test runs without errors

• TRG 5.09 Helm Test running properly

  Checks within TRG 5.09

  • TRG 5.09 A GitHub action exist which builds or uses the helm chart which gets released
  • TRG 5.09 The GitHub action can be triggered manually through Github WebUI manually running a workflow
  • TRG 5.09 Helm test verifies that the application is up and running

• TRG 5.10 Products need to support 3 versions at a time

  Checks within TRG 5.10

  • TRG 5.10 latest (K8s version 1.25)
  • TRG 5.10 latest - 1 (K8s version 1.24)
  • TRG 5.10 latest - 2 (K8s version 1.23)

• TRG 5.11 Upgradeability PRERELEASE

  Checks within TRG 5.11

  • TRG 5.11 Based on the Helm test workflow, you must provide a GitHub action which takes the latest released helm chart, does an installation of it and then execute the upgrade to the current / new version.

TRG 6 Released Helm Chart

• TRG 6.01 Released Helm Chart

TRG 7 Open Source Governance

• TRG 7.01 Legal Documentation

• TRG 7.02 License and copyright header

• TRG 7.03 IP checks for project content

• TRG 7.04 IP checks for 3rd party content

  Checks within TRG 7.04

  • TRG 7.04 DEPENDENCIES file is up-to-date and reflects the current use of the 3rd party content
  • TRG 7.04 all libraries listed there should have the status "approved"
  • TRG 7.04 no libraries with status "rejected"
  • TRG 7.04 for libraries with status "restricted", the according IP issues must be present (issue number in the source column)

• TRG 7.05 Legal information for distributions

• TRG 7.06 Legal information for end user content

• TRG 7.07 Legal notice for documentation

Hints

Information Sharing

[SebastianBezold]

Accidentally closed by PR, reopening

[SebastianBezold]

Hi @drcgjung,

From my point of view, #34 should be merged, to have an up-to-date version of the DEPENDENCIES.
#35 would also be important, since I could not test the Chart manually. It does not install, with just the default config (#31).

Afterwards, we could create the final release for knowledge-agents-edc

[SebastianBezold]

Hi @drcgjung,

while there are still issue, that should be addressed, I think we could create the final release for Tractus-X 3.2.
#27 indicates the version could be v1.9.7. I guess the "-SNAPSHOT" should not be used for the version that is mentioned in Tractus-X 3.2. Is there a specific workflow that you have in mind for releasing. A lot of other teams just release from "main" by creating a git tag, that builds the docker images with that tag. But there are also other options. What would you prefer?

[florianrusch-zf]

Maybe I'm blind, but I can't find the INSTALL.md file. As the checkbox is ticked, did I missed something?

Never mind! I discovered the respective section in the README.md

[SebastianBezold]

Maybe I'm blind, but I can't find the INSTALL.md file. As the checkbox is ticked, did I missed something?

Never mind! I discovered the respective section in the README.md

Yes exactly. The checks boxes are more of a reminder for me personally, when I cannot finish the checks in one run. So if I found a proper section in the README, I already ticked the INSTALL.md

[drcgjung]

Maybe I'm blind, but I can't find the INSTALL.md file. As the checkbox is ticked, did I missed something?

Never mind! I discovered the respective section in the README.md

sorry for the confusion and thanks for the heads up , I did not really find a good way to

• document the java binary configuration per module
• document the docker image configuration per application (multiple modules)
• document the helm chart configuration (several or variants of docker images)
• document the whole umbrella

without redundancy and ideal interconnections (even when one md is pushed into docker or into a jar)

So I more or less tried to put all into the Readme.md and or the docs/

there is room for improvement I see that now, got a supporter now with a fresh view on the documentation so this will definitely get better.

[SebastianBezold]

Closing, since there is already a new release ongoing.
See #128