Bump magefile/mage-action from 3.1.0 to 4.0.0 (#606)
Bumps magefile/mage-action from 3.1.0 to 4.0.0.
updated-dependencies:
- dependency-name: magefile/mage-action dependency-version: 4.0.0 dependency-type: direct:production update-type: version-update:semver-major …
Signed-off-by: dependabot[bot] support@github.com Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
版权所有:中国计算机学会技术支持:开源发展技术委员会
京ICP备13000930号-9
京公网安备 11010802032778号
Chart Releaser
Helps Turn GitHub Repositories into Helm Chart Repositories
cris a tool designed to help GitHub repos self-host their own chart repos by adding Helm chart artifacts to GitHub Releases named for the chart version and then creating anindex.yamlfile for those releases that can be hosted on GitHub Pages (or elsewhere!).Installation
Binaries (recommended)
Download your preferred asset from the releases page and install manually.
Homebrew
Go get (for contributing)
Docker (for Continuous Integration)
Docker images are pushed to the helmpack/chart-releaser Quay container registry. The Docker image is built on top of Alpine and its default entry-point is
cr. See the Dockerfile for more details.Common Usage
Currently,
crcan create GitHub Releases from a set of charts packaged up into a directory and create anindex.yamlfile for the chart repository from GitHub Releases.Dealing with charts that have dependencies
Unfortuntely the releaser-tool won’t automatically add repositories for dependencies, and this needs to be added to your pipeline (example), prior to running the releaser, like this:
Create GitHub Releases from Helm Chart Packages
Scans a path for Helm chart packages and creates releases in the specified GitHub repo uploading the packages.
Create the Repository Index from GitHub Releases
Once uploaded you can create an
index.yamlfile that can be hosted on GitHub Pages (or elsewhere).Usage with a private repository
When using this tool on a private repository, helm is unable to download the chart package files. When you give Helm your username and password it uses it to authenticate to the repository (the index file). The index file then tells Helm where to get the tarball. If the tarball is hosted in some other location (Github Releases in this case) then it would require a second authentication (which Helm does not support). The solution is to host the files in the same place as your index file and make the links relative paths so there is no need for the second authentication.
#123 solve this by adding a
--packages-with-indexflag to the upload and index commands.Prerequisites
Have a Github token with the right permissions (SSO enabled for entreprise) and Github Pages configured.
Usage
Here are the three commands you must run for a chart to end-up hosted in the root directory of your Github page and be accessible :
Don’t forget the
--skip-existingflag in the upload command to avoid getting a422 Validation Failederror.Example
With a testChart helm chart in the root of your repository :
You will obtain the .tgz in the ./cr-release-pacakges
Do the two followng commands :
You should obtain a release of your chart as well as the .tgz in the root of your github-pages branch.
With the
index.yamlthat references each chart and every different versions of those charts :Configuration
cris a command-line application. All command-line flags can also be set via environment variables or config file. Environment variables must be prefixed withCR_. Underscores must be used instead of hyphens.CLI flags, environment variables, and a config file can be mixed. The following order of precedence applies:
Examples
The following example show various ways of configuring the same thing:
CLI
Environment Variables
Config File
config.yaml:Config Usage
crsupports any format Viper can read, i.e. JSON, TOML, YAML, HCL, and Java properties files.Notice that if no config file is specified,
cr.yaml(or any of the supported formats) is loaded from the current directory,$HOME/.cr, or/etc/cr, in that order, if found.Notes for Github Enterprise Users
For Github Enterprise,
chart-releaserusers need to setgit-base-urlandgit-upload-urlcorrectly, but the correct values are not always obvious to endusers.By default they are often along these lines:
If you are trying to figure out what your
upload_urlis try to use a curl command like this:curl -u username:token https://example.com/api/v3/repos/org/repo/releasesand then look forupload_url. You need the part of the URL that appears beforerepos/in the path.Common Error Messages
During the upload, you can get the following error :
You can solve it by adding the
--skip-existingflag to your command. More details can be found in #101 and in #111 that solved this.Known Bug
Currently, if you set the upload URL incorrectly, let’s say to something like
https://example.com/uploads/, thencr uploadwill appear to work, but the release will not be complete. When everything is working there should be three assets in each release, but instead, there will only be two source code assets. The third asset is missing and is needed by Helm. This issue will become apparent when you runcr indexand it always claims that nothing has changed, because it can’t find the asset it expects for the release.It appears like the go-github Do call does not catch the fact that the upload URL is incorrect and passes back the expected error. If the asset upload fails, it would be better if the release was rolled back (deleted) and an appropriate log message is displayed to the user.
The
cr indexcommand should also generate a warning when a release has no assets attached to it, to help people detect and troubleshoot this type of problem.