Changes for v0.2.0 #38
Conversation
dc92712 to
5c41358
Compare
9364c98 to
9f29f29
Compare
22e9698 to
f554c96
Compare
|
FYI: while this doesn't directly solve #6, since we are committing the charts/, assets/ and index.yaml in the Staging Branch as part of the PR itself, any time a .patch file is generated will be caught during the PR itself. Therefore, I think this change addresses the underlying issue even if there is no actual changes being introduced to the build scripts on prepare. |
There was a problem hiding this comment.
@aiyengar2
Awesome work! I cannot wait to use this new version of charts-build-scripts!
The PR looks good to me overall. I reviewed all changes but did not run the code.
Co-authored-by: Jiaqi Luo <6218999+jiaqiluo@users.noreply.github.com>
|
|
||
| ### Porting over Charts / Assets from another Branch | ||
|
|
||
| In the Staging branch, porting over charts from another branch (e.g. `dev-v2.x+1`) requires you to copy the contents of that branch into your Staging branch, which can be done with the following simple Bash script. However, you will need to manually regenerate the Helm index since you only want the index.yaml on the Staging branch to be updated to include the new chart. |
There was a problem hiding this comment.
I'm a little confused on this part. Aren't dev and staging the same now ? Meaning isn't dev-v2.5 the staging branch ? The goal of this script I'm guessing is to move across release lines, not entirely clear.
As for the whole bash script below, can't you just copy paste a folder from one versions branch to another ? Script below is not intuitive, I don't get the point of the forked branch / port.
There was a problem hiding this comment.
Yeah dev and staging are the same now. The goal of this script is, let's say, moving from dev-v2.6 to dev-v2.5.
You don't want to necessarily maintain two versions of the chart in packages/, so you can make the commit to dev-v2.6 with the packages/ changes and simply port the charts, assets, and index.yaml over to dev-v2.5.
Or, if we use @nickgerace 's idea of having a single dev-v2.x branch that contains packages, this would be the normal process to make that version available in dev-v2.5 or dev-v2.6 branches (e.g. identical to what we do today with making a commit to master and then porting it to release/v2.5 and release/v2.6.
Copying and pasting a folder isn't sufficient since you also need to regenerate the Helm index. But basic idea is the same yeah; you need to copy the charts/, the assets/ and regenerate the Helm index to port over just the generated resources.
You can't do a simple cherry-pick across branches since the index.yaml may have conflicts.
There was a problem hiding this comment.
No cherry-pick makes sense, as does index.yaml regeneration. But why not just copy package/logging folder, swap branches, and then run make charts and make validate again ?
There was a problem hiding this comment.
You’ll be committing 2 versions of the logging chart. This is fine, as long as you keep both copies up to date, but if all you want is to make the asset available it makes more sense to have a single source of truth.
e.g. let’s say you miss a file change in one of them. It’s possible you could end up with two charts with different contents and the same version number.
|
I think the staging/prod branches look good, thanks for doing this. |
That's expected right? |
There was a problem hiding this comment.
I do see another small problem, fleet has 5000 as patch version:
That's expected right?
5is the patch and000is the packageVersion. Discussing this in #38 (comment).
Pushed change to switch to 2 digit packageVersions, this should now be 500
Highlights:
make sync,make rebasemake docstomake templatemake validateand removed a ton of files that were overly complex due to new requirements. See below for more detailsRelated Issue: rancher/rancher#32199