Use an alternative ci workflow that does not require using Generate-DockerImageVariants module
Closed this issue · 7 comments
As described, until we are settled on the conventions that should be adopted across our docker image repositories.
renamed the issue.
Currently, the workflow for all our theohbrothers/docker-<binary> repos using Generate-DockerImageVariants module include important aspects of a good OSS project, see: startersclan/docker-steamcmd#8 (comment)
- docker build tests in PR
- docker build / push on
master - changelog generator startersclan/docker-steamcmd#8 (comment)
- automatic releases for semver / calver
Whereas repos such as startersclan/docker-steamcmd which do not use it are missing those very aspects, see startersclan/docker-steamcmd#10 .
@joeltimothyoh For log retention for GHW, see startersclan/docker-steamcmd#10 (comment).
As of this writing, log retention is limited to 90 days for all public repos regardless of github subscription.
I’m not sure if it is fair to preclude GHW as a CI provider based on the reason of poor log retention alone. Here’s some links that AZP is going to be succeeded by GHW:
The lack of log retention removes transparency and traceability in OSS projects and is alone sufficient reason for not using a CI provider. Most other providers don’t toy with the logs the way GHA or azp which it’s based off does. Just even begin imagining using GitLab CI/CD with expiring logs and see where you get with long-term infrastructure.
@joeltimothyoh what about all of the other open source projects, they will suffer the same issue if they use GHW. But i think because open source generally moves fast, log retention isn't very important. Log retention is generally more important for CD, not so much for CI.
I think we agree on why they move fast. @leojonathanoh
it's a mentality i guess. but for GHW to use this as an excuse for not supporting OSS with greater log retention, is rather sad