Relevant source files

The following files were used as context for generating this wiki page: - [cr.sh](https://github.com/Trancendos/nexus-helm-chart-releaser-action/blob/main/cr.sh) - [action.yml](https://github.com/Trancendos/nexus-helm-chart-releaser-action/blob/main/action.yml) - [README.md](https://github.com/Trancendos/nexus-helm-chart-releaser-action/blob/main/README.md) - [CODE_OF_CONDUCT.md](https://github.com/Trancendos/nexus-helm-chart-releaser-action/blob/main/CODE_OF_CONDUCT.md) - [helm/chart-releaser](https://github.com/helm/chart-releaser) (External reference used by the action)

# Extending the Action Extending the Nexus Helm Chart Releaser Action involves modifying its core execution logic, which is primarily driven by a shell-based orchestration layer that bridges GitHub Actions and the `chart-releaser` CLI. The action is designed to automate the packaging, GitHub releasing, and Nexus repository uploading of Helm charts by detecting changes within a specified directory. The system relies on a composite action definition that translates GitHub workflow inputs into command-line arguments for a central execution script, `cr.sh`. This modular approach allows developers to extend functionality by either modifying the input schema in `action.yml` or enhancing the bash functions within the core script to support additional lifecycle stages or alternative repository managers. Sources: [action.yml:32-55](), [README.md:3-8](), [cr.sh:42-88]() ## Core Execution Architecture The action follows a linear execution flow starting from the GitHub Action runner, passing through an argument parsing phase, and ending with file uploads to a Nexus instance. ```mermaid flowchart TD Start([Workflow Trigger]) --> ActionYaml[action.yml] ActionYaml --> ArgParse[Parse Arguments] ArgParse --> GitCheck[Lookup Latest Tag] GitCheck --> ChangeDetect[Identify Changed Charts] ChangeDetect --> |Changes Found| InstallCR[Install chart-releaser] InstallCR --> Package[Package Charts] Package --> UploadGH[Upload to GitHub Releases] UploadGH --> PushNexus[Push to Nexus Repo] PushNexus --> End([Success]) ChangeDetect --> |No Changes| End ``` The diagram above illustrates the high-level logic flow from the initial GitHub workflow trigger to the final push to the Nexus Repository. Sources: [cr.sh:42-88](), [action.yml:34-55]() ## Modifying Input Parameters To extend the action's capabilities, new inputs must be defined in the `action.yml` file. These inputs are then mapped to the `args` array which is passed to the execution script. | Input Key | Description | Default | Required | | :--- | :--- | :--- | :--- | | `version` | `chart-releaser` CLI version | `v1.2.1` | No | | `config` | Path to `cr.yaml` config file | N/A | No | | `charts_dir` | Directory containing Helm charts | `charts` | No | | `charts_repo_url` | Target Nexus repository URL | N/A | Yes | | `username` | Nexus authentication username | N/A | Yes | | `password` | Nexus authentication password | N/A | Yes | Sources: [action.yml:8-29](), [README.md:16-24]() ## Script Logic and Extension Points The `cr.sh` script is structured into discrete functions that can be individually extended or overridden to change the action's behavior. ### Change Detection Logic The script identifies which charts need to be processed by comparing the current state against the latest Git tag. This is handled by `lookup_latest_tag` and `lookup_changed_charts`. ```bash lookup_changed_charts() { local commit="$1" local changed_files changed_files=$(git diff --find-renames --name-only "$commit" -- "$charts_dir") local depth=$(( $(tr "/" "\n" <<< "$charts_dir" | sed '/^$\.$*$/d' | wc -l) + 1 )) local fields="1-${depth}" cut -d '/' -f "$fields" <<< "$changed_files" | uniq | filter_charts } ``` Sources: [cr.sh:185-194]() ### Nexus Integration The final stage of the action involves an HTTP `PUT` request via `curl` to the Nexus repository. This is the primary point for extending support for different repository managers or authentication methods. ```mermaid sequenceDiagram participant S as cr.sh participant CR as chart-releaser CLI participant GH as GitHub API participant NX as Nexus Repo S->>CR: cr package CR-->>S: Generated .tgz S->>CR: cr upload CR->>GH: Create Release & Upload Asset S->>NX: curl --upload-file NX-->>S: 201 Created / 200 OK ``` The sequence diagram details the interaction between the local script, the `chart-releaser` utility, and the remote APIs (GitHub and Nexus). Sources: [cr.sh:207-228](), [README.md:71-79]() ### Environment Requirements Any extension must ensure the `CR_TOKEN` environment variable is available, as it is mandatory for the `chart-releaser` tool to interact with GitHub. - **Variable:** `CR_TOKEN` - **Purpose:** GitHub Authentication for creating releases. - **Source:** Typically mapped to `${{ secrets.GITHUB_TOKEN }}`. Sources: [README.md:28-30](), [cr.sh:54]() ## Tool Installation and Caching The action installs the `chart-releaser` CLI dynamically. It utilizes the `$RUNNER_TOOL_CACHE` to avoid redundant downloads across steps within the same runner session. ```bash install_chart_releaser() { local arch=$(uname -m) local cache_dir="$RUNNER_TOOL_CACHE/ct/$version/$arch" if [[ ! -d "$cache_dir" ]]; then mkdir -p "$cache_dir" curl -sSLo cr.tar.gz "https://github.com/helm/chart-releaser/releases/download/%24version/chart-releaser_%24%7Bversion#v}_linux_amd64.tar.gz" tar -xzf cr.tar.gz -C "$cache_dir" export PATH="$cache_dir:$PATH" fi } ``` Sources: [cr.sh:147-165]() ## Conclusion Extending the Nexus Helm Chart Releaser Action requires a dual-layered approach: modifying the `action.yml` to expose new configurations and updating the `cr.sh` script to implement new logic. The script's modular function-based design facilitates adding new stages to the Helm chart lifecycle, such as linting or custom metadata injection, before the final upload to Sonatype Nexus.