Update CI caches

[MilanKlausz]

• [x] Add workflow dipatch input option run the workflows without running the tests.
• [ ] Remove the date from the cache names (used to enforce the cration of new caches before there was an option to handle(delete) caches by hand)
• [ ] Make sure to expose the option to workflows in other repos (dgcode, dgcode_private_projects) reusing workflows in this repo

[tkittel]

Isn't it safer to have the date (or another "build number") in the key, rather than relying on remembering to delete all the caches? After all, the one modifying the cache keys might not have permissions to manually delete all the caches in repos using the actions, if I understand the setup correctly?

[MilanKlausz]

Including a hardcoded date in the key is misleading because it doesn't really ensure that the cache in use was actually created on that date. If a cache is deleted later on for some reason (e.g., being unsused for some time or getting deleted after reaching cache storage quota), it will be recreated in the next run on a different date automatically.

You are right, though, that a modifiable part of the key would be a safer and more accessible way to ensure that we are recreating the caches.

[tkittel]

Well, I see your point, but for me the date in the key indicates when the key was configured, not necessarily when the key was rebuilt. It could also be a config number, i.e. an integer which we increment every time. However, a date is simpler to keep track of IMO (of course if editing more than once in a day one much postfix something unique on the date). But of course, if you can think of a better thing than a date then that is fine with me as well. In my experience having the key change and therefore force downstream changes is much more manageable and less likely to give cache-errors.

[MilanKlausz]

I'm convinced. The dates can stay in the keys.