Versioning strategy for custom actions and workflows

[devtobi]

Problem
I created a reusable workflow for CodeQL in this repository (see #26) thats used in it-at-m/refarch-templates#352.
This is achieved by the line:

uses: it-at-m/.github/.github/workflows/codeql.yml@main

However the reference to main has potential side effects when the workflow gets updated on the main branch of this repository.
Thats why we should introduce a versioning strategy for all custom actions and workflows. (either via Branch names or Git Tags).

On top of that it would be interesting if Renovatebot is able to bump to new version numbers when the actions/workflows get new releases. If not I'd encourage a simple versioning scheme like v1, v2 etc. If Renovatebot is capable, we could use a more fine granular version like 1.0.0 as well.

• move actions from .github to lhm_actions repo #110
• change project and refarch(-template) workflows to use actions in lhm_actions #111
• create workflow to release actions in lhm_actions #112
• change renovate bot in lhm-refarch to automerge patch and minor versions of lhm_actions #113

[hupling]

Im Moment haben wir auch eine Versionierung, sie ist halt nicht menschenlesbar, sondern besteht aus den Commit-Hashes.

[hupling]

Wenn wir die Workflow-Templates aus den Appstore entfernen https://github.com/it-at-m/.github/tree/main/workflow-templates und nur noch in den refarch-templates pflegen. So spart man sich auch die doppelte Pflege. Intern in Gitlab haben wir es auch so gemacht.

So sparst du dir auch immer, die Abhängigkeiten AppStore Workflow und den Actions. So muss man da nicht gleichzeitig bei einem Release die Versionsnummer in workflow-templates und .github/actions hochzählen.

Außerdem könnten wir dieses spezial Repo .github als SPS wieder verlassen und unser eigenes erstellen

[hupling]

wir schauen uns nochmal an, wie es andere Opensource Projekte machen

[hupling]

@ejcsid also bei Opensource Projekten ist es so, dass sogar jede einzelne Action ein separates Repo ist. https://github.com/orgs/actions/repositories?type=all bzw in Gitlab https://gitlab.com/components

Daher fände ich zwei Repos nicht schlecht. also einmal mit den Workflows die die Projekte verwenden https://github.com/it-at-m/.github/tree/main/workflow-templates und einmal die Actions/Workflow-Templates, die von denen aufgerufen werden. https://github.com/it-at-m/.github/tree/main/.github

[ejcsid]

👍 - ist mir gestern auch aufgefallen, dass github ein eigenes Repo für die Actions hat und bin deiner Meinung, dass wir die Workflows und die Actions trennen sollten.

[ejcsid]

Requested repo

• name: actions
• Access for team sps

[ejcsid]

Requested repo

• name: actions
• Access for team sps

New repo lhm_actions added: https://github.com/it-at-m/lhm_actions