lunny/helm-chart
1
0
Fork 0
Code Issues 36 Pull Requests 14 Actions Packages Projects Releases 93 Wiki Activity

1.15.4 #230

Merged
techknowlogick merged 1 commits from refs/pull/230/head into master 2021-10-16 16:08:18 +00:00
Conversation 7 Commits 1 Files Changed 1 +1 -1
techknowlogick commented 2021-10-15 18:08:44 +00:00 (Migrated from gitea.com)
Copy Link
No description provided.
justusbunsi (Migrated from gitea.com) approved these changes 2021-10-16 09:43:30 +00:00
justusbunsi commented 2021-10-16 09:48:01 +00:00 (Migrated from gitea.com)
Copy Link

We could reduce the occurrences of the version to exactly 1 within the Chart.yaml. In values.yaml we can leave the tag empty and document that this will default to the value from Chart.yaml. In the docs we may link to the line in the Chart.yaml or somehow dynamically extract the value.

I think, I'll drop a PR for that.

We could reduce the occurrences of the version to exactly 1 within the `Chart.yaml`. In `values.yaml` we can leave the tag empty and document that this will default to the value from `Chart.yaml`. In the docs we may link to the line in the `Chart.yaml` or somehow dynamically extract the value. I think, I'll drop a PR for that.
pat-s commented 2021-10-16 10:30:54 +00:00 (Migrated from gitea.com)
Copy Link

Would there be major downsides in defaulting to :1? I see potential ones if the minor version changes (e.g. from 1.14 to 1.15).

This again reminds me how great it would be to have a rolling tag for minor releases, e.g. 1.14, 1.15 - which auto-updates patch releases.

This would reduce the PR version bumps a lot and prevent issues when there are new minor releases.

Would there be major downsides in defaulting to `:1`? I see potential ones if the minor version changes (e.g. from 1.14 to 1.15). This again reminds me how great it would be to have a rolling tag for minor releases, e.g. `1.14`, `1.15` - which auto-updates patch releases. This would reduce the PR version bumps a lot and prevent issues when there are new minor releases.
pat-s (Migrated from gitea.com) approved these changes 2021-10-16 10:31:05 +00:00
justusbunsi commented 2021-10-16 10:39:48 +00:00 (Migrated from gitea.com)
Copy Link

Would there be major downsides in defaulting to :1? I see potential ones if the minor version changes (e.g. from 1.14 to 1.15).

This again reminds me how great it would be to have a rolling tag for minor releases, e.g. 1.14, 1.15 - which auto-updates patch releases.

This would reduce the PR version bumps a lot and prevent issues when there are new minor releases.

I mean just have the whole version one time in the whole repository. :) It should still be the whole major.minor.path specification.

> Would there be major downsides in defaulting to `:1`? I see potential ones if the minor version changes (e.g. from 1.14 to 1.15). > > This again reminds me how great it would be to have a rolling tag for minor releases, e.g. `1.14`, `1.15` - which auto-updates patch releases. > > This would reduce the PR version bumps a lot and prevent issues when there are new minor releases. I mean just have the whole version one time in the whole repository. :) It should still be the whole `major.minor.path` specification.
justusbunsi commented 2021-10-16 13:42:45 +00:00 (Migrated from gitea.com)
Copy Link

?‍♂️ You mean the :1 tag of the image. Misunderstood you @pat-s, sorry. TBH, using such tag may be more flexible for us using it here but would also mean that you never have a reproducable Helm Chart release.

?‍♂️ You mean the `:1` tag of the image. Misunderstood you @pat-s, sorry. TBH, using such tag _may_ be more flexible for us using it here but would also mean that you never have a reproducable Helm Chart release.
pat-s commented 2021-10-16 16:09:45 +00:00 (Migrated from gitea.com)
Copy Link

I mean just have the whole version one time in the whole repository. :) It should still be the whole major.minor.path specification.

Yeah my comment was slightly unrelated and should maybe have gone in a separate issue.

TBH, using such tag may be more flexible for us using it here but would also mean that you never have a reproducable Helm Chart release.

Yeah I know, it's probably better to fix it by default to a static tag.

I think nevertheless that "minor" rolling tags would be a great thing to have - but this is a discussion for Gitea itself, not for the helm chart.

> I mean just have the whole version one time in the whole repository. :) It should still be the whole major.minor.path specification. Yeah my comment was slightly unrelated and should maybe have gone in a separate issue. > TBH, using such tag may be more flexible for us using it here but would also mean that you never have a reproducable Helm Chart release. Yeah I know, it's probably better to fix it by default to a static tag. I think nevertheless that "minor" rolling tags would be a great thing to have - but this is a discussion for Gitea itself, not for the helm chart.
Sign in to join this conversation.
Reviewers
No Reviewers
justusbunsi
pat-s
Labels
Clear labels
has/backport
in progress
invalid
kind/breaking
kind/bug
kind/build
kind/dependency
kind/deployment
kind/docs
kind/enhancement
kind/feature
kind/lint
kind/proposal
kind/question
kind/refactor
kind/security
kind/testing
kind/translation
kind/ui
need/backport
priority/critical
priority/low
priority/maybe
priority/medium
reviewed/duplicate
reviewed/invalid
reviewed/wontfix
skip-changelog
status/blocked
status/needs-feedback
status/needs-reviews
status/wip
upstream/gitea
upstream/other
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: lunny/helm-chart#230
No description provided.
Delete Branch "refs/pull/230/head"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?