Refactor central management of linter rulesets (the resprctive files like `.yamllint.yml`

[sebastian-sommerfeld-io]

There is no bootstrap script anymore. Somehow make sure linter definitons are synced into all projects. Maybe something siilar to a jarvis module?

Think about this

They should be synced into the repos somehow to avoid different / outdated rules across the repos. Rules should be the same everywhere.

• [x] Add .vscode to .folderslintrc
• [x] Extend "CI" pipeline for every repo. Validate in every repo (exept .github) that there are no ISSUE_TEMPLEATE folders and no PULL_REQUEST_TEMPLATE files. Make part of the reusable workflow (module-ci-lint.yml). Remember the if NOT .github check.
• [x] update Docs
  • [x] Document new workflow
  • [x] Update "Module: CI Linter" in docs/modules/ROOT/partials/README.adoc: no need to manually manage linter definitions for each repo ... Document which files are written automatically

Implementation idea

Based on https://medium.com/@ericchap/how-to-centralize-your-workflow-management-in-github-4ee49283790c

• [x] Put linter definitions here
• Add workflow that
  • [x] reads all repos using github cli
  • [x] creates a matrix (one job for each repo)
  • [x] checkout code for respective repo
  • [x] put linter files
  • [x] commit and push
    • [x] :zap: Error: Error: Pushing to https://github.com/sommerfeld-io/infrastructure-config - remote: Permission to sommerfeld-io/infrastructure-config.git denied to github-actions[bot]. ... looks like the workflow does not have permissions to push to any repo but its own (= .github)
    • [x] 💡 SOLUTION: don‘t run in matrix. Create reusable workflow for each repo. Pro: no permission issues … Contra: every repo must set up a workflow on its own (initially).
      • [x] Implement Reusable Workflow and use n every repo
      • [x] Remove - src/main/github-config/* from .github/workflows/housekeeping-repo.yml in all repos
    • [x] In case this cannot be done from .github repo and should be a reusable workflow, archive the matrix setup shomehow. maybe write some sort of blog post in the website repo (create a dedicated blog module). —> put the not working workflow file into the adr and explain based on this code..
    • [x] Write ADR and explain while there are some Workflows in every repo and others, wich configure things for all repos in.a matrix, in .GitHub repo. Update docs/modules/ADR/pages/adr-2023-07-16-global-update-workflows-vs-reusable-workflows.adoc
• [x] Decide if .github should use the workflow as well or if the files from this projects root is the true source (avoiding a dedicate "resources" directory)

[sebastian-sommerfeld-io]

ADR Memos / input

Token scope

See: https://stackoverflow.com/questions/71068476/accessing-another-repository-with-github-cli-in-github-actions

The GITHUB_TOKEN is scoped only to the triggering repository. If you need to access any resources in other repositories or in other accounts then you need to pass a token with a wider scope to the checkout step. This can be a GitHub App token, a Personal Access Token etc.