Internal: Clone Release workflow [TMZ-803]

[hein-obox]

✨ PR Description

Purpose: Add Hello Elementor release workflow automation by cloning and adapting release preparation system from Hello Commerce.

Main changes:

• Created new release-preparation.yml workflow for automated versioning, building, and GitHub release creation
• Added specialized actions for theme version bumping, changelog extraction, and PR creation
• Implemented version validation script to ensure consistency across PHP, CSS, and readme files
• Added build action with package version handling and zip file creation for releases

Generated by LinearB AI and added by gitStream.
_{AI-generated content may contain inaccuracies. Please verify before using. We'd love your feedback! 🚀}

The best fix is to pass user-controlled inputs (like BUILD_ZIP_PATH and CHANGELOG_FILE) to the script as environment variables using the env: block in the step, and to reference those entries within the shell script using the native shell variable syntax ("$BUILD_ZIP_PATH"). This ensures the shell receives the literal input as a variable, not as an evaluated shell statement, which prevents injection vulnerabilities.

Specifically, in file .github/actions/create-theme-release-release/action.yml:

• Update the "Verify files exist" and "Release summary" steps to set all input values used in shell commands under an env: block.
• Update all script references from ${{ inputs.BUILD_ZIP_PATH }} (and similar) to "$BUILD_ZIP_PATH", etc.
• This fix involves only the lines within the two shell run: script steps.

---

To fix the problem, we should avoid using ${{ inputs.CHANGELOG_FILE }} directly inside command lines in run: blocks. The correct and safest fix is to:

1. Assign the expression value to an environment variable via the env: directive.
2. Reference the environment variable in the shell script using native shell syntax (e.g., $CHANGELOG_FILE) rather than further GitHub Action expressions.

Specifically, in the "Verify files exist" step, we should:

• Set CHANGELOG_FILE: ${{ inputs.CHANGELOG_FILE }} in the env: block.
• Replace any shell interpolations ${{ inputs.CHANGELOG_FILE }} with $CHANGELOG_FILE.

Do the same for other user-provided inputs (BUILD_ZIP_PATH) used in shell context for full coverage, but the flagged line is focused on CHANGELOG_FILE. Other usages (such as inside with: for actions) are not executed as shell scripts and thus are not susceptible in the same way.

No new external dependencies or method definitions are needed—just the use of existing GitHub Actions syntax.

---

To fix the issue, we should stop interpolating the expression ${{ inputs.BUILD_ZIP_PATH }} directly into the shell command. Instead, we should assign inputs.BUILD_ZIP_PATH (and similarly, inputs.CHANGELOG_FILE) to environment variables at the step level, and reference them in the shell using "${BUILD_ZIP_PATH}". This approach avoids code injection regardless of the value of the input, because the shell will not interpret injected special characters as part of its command structure. The fix should be applied to every occurrence where an untrusted input is interpolated directly, specifically lines 32, 33, 37, 38, 42, and 43 of the run: block in the "Verify files exist" step. The same should be done in other relevant steps if needed (but the error was raised for line 42). Changes are only within the shown code of the .github/actions/create-theme-release-release/action.yml file.

The solution consists of:

• Adding an env: block to the relevant step, assigning inputs.BUILD_ZIP_PATH and inputs.CHANGELOG_FILE to environment variables with safe names.
• Replacing all direct uses of ${{ inputs.BUILD_ZIP_PATH }} and ${{ inputs.CHANGELOG_FILE }} in the shell command with shell variable references $BUILD_ZIP_PATH and $CHANGELOG_FILE.

---

To fix this issue, we need to ensure that any user-controlled input (such as ${{ inputs.PRE_RELEASE }}) is not directly interpolated into the script with ${{ }} expression syntax. Instead, it should first be assigned to an environment variable using env: and then referenced with the shell's native variable expansion ($PRE_RELEASE). Specifically, assign PRE_RELEASE to an environment variable via the env key within the workflow step, and in the bash script, use "$PRE_RELEASE" instead of ${{ inputs.PRE_RELEASE }}. This change only needs to be applied to the step that outputs the release summary (the step beginning at line 59). No changes in business logic or function should occur, just a switch to safe variable expansion.

Required changes:

• In the "Release summary" step, add an env: section assigning PRE_RELEASE: ${{ inputs.PRE_RELEASE }}.
• On line 65, replace echo " - Pre-release: ${{ inputs.PRE_RELEASE }}" with echo " - Pre-release: $PRE_RELEASE" (i.e., use shell expansion).
• No new imports or dependencies required.

---

To fix this potential code injection vulnerability, the user-controlled input (BUILD_ZIP_PATH) should be passed to the shell script as an environment variable, rather than being directly interpolated into the script using ${{ ... }}. The correct pattern is to define an environment variable in the step (using env:), assign it the value from ${{ inputs.BUILD_ZIP_PATH }}, and then reference it inside the script using shell-native syntax ("$BUILD_ZIP_PATH"). This mitigates shell code injection risks. Lines 61-68 should be updated so that BUILD_ZIP_PATH and other user inputs used in echo and export statements are referenced from environment variables rather than interpolated directly. The environment variables can be set via the env: key of the step.

To mitigate the code injection risk, the recommended solution is to store the value of ${{ steps.create-release.outputs.html_url }} in an environment variable in the step, then reference that variable within the bash script using $RELEASE_URL (shell variable syntax) rather than ${{ ... }}. This avoids direct interpolation of potentially user-controlled values inside the shell command, preventing code injection. The required change is to add env: RELEASE_URL: ${{ steps.create-release.outputs.html_url }} to the step and replace the shell usage of ${{ steps.create-release.outputs.html_url }} with $RELEASE_URL in the relevant locations (line 67 and line 68). No extra dependencies or method definitions are required, just modifications in the YAML step configuration.

To resolve the code injection risk, the workflow should avoid directly interpolating ${{ steps.create-release.outputs.html_url }} into the shell script. Instead, set it first as an environment variable via the env: field of the step, then reference it using standard shell variable syntax ($RELEASE_URL) when writing to $GITHUB_ENV. This change is limited to the "Release summary" step: define an environment variable RELEASE_URL set to ${{ steps.create-release.outputs.html_url }} in the step definition and then reference it as $RELEASE_URL within the shell script on line 68. No other lines need to be changed.