-
Notifications
You must be signed in to change notification settings - Fork 35
Description
Per title, this is to track an improvement we've discussed that is necessary to support the BRO and PromFed workflows. While these repo have charts folders with chart files, these are "proto-templates" that have intentional placeholder values (which are invalid) that we replace at "build time" when a new tag is created.
See here: https://github.com/rancher/backup-restore-operator/releases/tag/v6.0.2
These two are charts:
rancher-backup-6.0.2.tgz
rancher-backup-crd-6.0.2.tgz
Essentially the idea I have would be that we use package.yaml like this:
auto: true
autoUseTags: true
url: https://github.com/rancher/backup-restore-operator.git
chartRepoBranch: release/v7.x
releaseFile: rancher-backup-%{tag}.tgz
additionalCharts:
- workingDir: charts-crd
upstreamOptions:
url: https://github.com/rancher/backup-restore-operator.git
chartRepoBranch: release/v7.x
releaseFile: rancher-backup-crd-%{tag}.tgz
crdOptions:
templateDirectory: crd-template
crdDirectory: templates
addCRDValidationToMainChart: trueNotice these new ones here:
autoUseTags: true
releaseFile: rancher-backup-%{tag}.tgz
Similar to auto the autoUseTags only exists at the top level and affects both the main chart and any additionalCharts configured. And similar to chartRepoBranch the new releaseFile will exist on the top level chart and any additionalCharts config files.
The autoUseTags setting simply configures the auto feature to work based on tags. In other words, it tracks what tags exist (based on the specific branch) and will increment tag version only based on that subset of tags. (Note by default, this can still work with exiting auto features and simply changes how build scripts manage the Git repo; tracking specific tags then using their hash versus using the HEAD of that branch)
The releaseFile field identifies the file-name (in template form) that the chart is released as. Note, this only works in combination with autoUseTags: true as using tags is a requirement of using Release artifacts. This field essentially does two things - maybe it should be two fields - first it implies "Use Release artifacts instead of Git files as the source" and the second is that it provides the file to use.
How would it work?
Essentially the same as how I think (assume) the auto bump stuff works now...but with some slight variation.
Use Git tags, but files from Git repo
I believe, this could be seen as similar to using the commit setting along with auto.
The current downside of using auto alone is that it always tracks HEAD commit. So if you merged a new PR after tagging a release, but before you run Chart Auto Bump; then your Chart PR would potentially have more changes compared to the Tagged version.
In the case where we work based off of tags, instead of targeting HEAD of the branch it would target the "newest tag" on that branch instead. Essentially after finding the latest tag on a given branch, then it would function similarly to if commit was used with that value.
Use Git tags, but files from GitHub Releases
The chart file needs to be sourced from GitHub Releases instead of the Git repo.
Similar to above, the Git Branch and then newest Tag on that branch would be resolved. Then using the releaseFile as a template the selected Tag (version) will be used to render the full file name. This allows for accurately selecting files with the tag in their name.
As example, if we set the value of releaseFile: rancher-backup-%{tag}.tgz and find the tag of v7.0.0-rc.1 - then we would expect the "rendered name" to be: rancher-backup-7.0.0-rc.1.tgz.