docker builds test in PR, docker builds on master, changelog generator, automatic releases
leojonathanoh opened this issue · 8 comments
Current
No docker builds test in PR, docker builds on master, changelog generator, automatic releases
Expectation
docker builds test in PR, docker builds on master, changelog generator, automatic releases
Discussion
The repo is missing many important aspects of a good OSS project:
- docker build tests in PR
- docker build / push on
master - changelog generator #8 (comment)
- automatic releases for semver / calver
Suggested improvements:
- Implement a ci that implements all of those missing aspects. See: #8 (comment).
Kindly again refer to #8 (comment).
Additionally, the expiring logs of GHA is unacceptable. I’m been thinking of moving the building to somewhere else.
Closing this issue as I fundamentally disagree with the conventions adopted by https://github.com/theohbrothers/Generate-DockerImageVariants/tree/ea09c2f54a8e98e447c51e800c36cac915bae8ac if the intention for opening this issue is for adopting its workflow together with GHA.
Kindly again refer to #8 (comment).
Closing this issue as I fundamentally disagree with the conventions adopted by https://github.com/theohbrothers/Generate-DockerImageVariants/tree/ea09c2f54a8e98e447c51e800c36cac915bae8ac if the intention for opening this issue is for adopting its workflow together with GHA.
i opened this issue for the points listed in OP, for us to keep an open mind about improvements for managing docker-* repositories. While https://github.com/theohbrothers/Generate-DockerImageVariants workflow is good, if there might be a better workflow than GHA and Generate-DockerImageVariants, i'd be open to it. So this issue should not have been closed.
updated OP with better clarity about a suggested improvement.
Additionally, the expiring logs of GHA is unacceptable. I’m been thinking of moving the building to somewhere else.
If poor log retention is the main hindrance to adopting GHA (which is imo the best ci when working in github), then if GHA has better log retention now, that is sufficient reason to move away from all non-git-server-native ci (i.e. anything other than GHA when working on github).
If poor log retention is the main hindrance to adopting GHA (which is imo the best ci when working in github), then if GHA has better log retention now, that is sufficient reason to move away from all non-git-server-native ci (i.e. anything other than GHA when working on github).
@joeltimothyoh https://docs.github.com/en/enterprise-cloud@latest/organizations/managing-organization-settings/configuring-the-retention-period-for-github-actions-artifacts-and-logs-in-your-organization. Quote:
For public repositories: you can change this retention period to anywhere between 1 day or 90 days.
For private, internal, and GitHub Enterprise Server repositories: you can change this retention period to anywhere between 1 day or 400 days.
I managed to configure log retention to 400 days in https://github.com/organizations/theohbrothers/settings/actions.
But within individual public repos, the log retention period cannot be greater than 90 days. https://github.com/theohbrothers/docker-packer/settings/actions. This seems to apply to all public repos, regardless of github subscription.
Kindly refer to theohbrothers/Generate-DockerImageVariants#57 (comment).
Closing.
we can continue the discussion in theohbrothers/Generate-DockerImageVariants#57 (comment), but this issue should at least be kept open for discussion for the sake of adopting a better workflow in future.