Refactor Github Action per b/485167538#19294
Conversation
|
Hi @google-admin, thank you so much for your contribution to Gemini CLI! We really appreciate the time and effort you've put into this. We're making some updates to our contribution process to improve how we track and review changes. Please take a moment to review our recent discussion post: Improving Our Contribution Process & Introducing New Guidelines. Key Update: Starting January 26, 2026, the Gemini CLI project will require all pull requests to be associated with an existing issue. Any pull requests not linked to an issue by that date will be automatically closed. Thank you for your understanding and for being a part of our community! |
|
Hi there! Thank you for your contribution to Gemini CLI. To improve our contribution process and better track changes, we now require all pull requests to be associated with an existing issue, as announced in our recent discussion and as detailed in our CONTRIBUTING.md. This pull request is being closed because it is not currently linked to an issue. Once you have updated the description of this PR to link an issue (e.g., by adding How to link an issue: Thank you for your understanding and for being a part of our community! |
Summary of ChangesHello @google-admin, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request systematically refactors several GitHub Actions to align with current best practices for input handling. The primary goal is to enhance the robustness and reliability of these actions by ensuring that all workflow inputs are correctly and consistently accessed within their respective Highlights
Changelog
Ignored Files
Activity
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
|
Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). View this failed invocation of the CLA check for more information. For the most up to date status, view the checks section at the bottom of the pull request. |
There was a problem hiding this comment.
Code Review
This pull request is an automated refactoring to improve the security of GitHub Actions by using environment variables instead of direct context interpolation in scripts. The changes are generally correct and follow this security best practice. However, I've found a few instances where the newly introduced environment variables are used without quotes in shell commands. This could still lead to potential script injection or unexpected behavior if the variable values contain special characters. I've added suggestions to quote these variables for improved robustness and security.
| --workspace="${INPUTS_CORE_PACKAGE_NAME}" \ | ||
| --no-tag | ||
| npm dist-tag rm ${{ inputs.core-package-name }} false --silent | ||
| npm dist-tag rm ${INPUTS_CORE_PACKAGE_NAME} false --silent |
There was a problem hiding this comment.
For robustness and to prevent potential shell injection issues, it's best practice to quote environment variables when they are used as arguments in shell commands. The variable ${INPUTS_CORE_PACKAGE_NAME} should be enclosed in double quotes.
npm dist-tag rm "${INPUTS_CORE_PACKAGE_NAME}" false --silent| --workspace="${INPUTS_CLI_PACKAGE_NAME}" \ | ||
| --no-tag | ||
| npm dist-tag rm ${{ inputs.cli-package-name }} false --silent | ||
| npm dist-tag rm ${INPUTS_CLI_PACKAGE_NAME} false --silent |
There was a problem hiding this comment.
For robustness and to prevent potential shell injection issues, it's best practice to quote environment variables when they are used as arguments in shell commands. The variable ${INPUTS_CLI_PACKAGE_NAME} should be enclosed in double quotes.
npm dist-tag rm "${INPUTS_CLI_PACKAGE_NAME}" false --silent| --workspace="${INPUTS_A2A_PACKAGE_NAME}" \ | ||
| --no-tag | ||
| npm dist-tag rm ${{ inputs.a2a-package-name }} false --silent | ||
| npm dist-tag rm ${INPUTS_A2A_PACKAGE_NAME} false --silent |
There was a problem hiding this comment.
For robustness and to prevent potential shell injection issues, it's best practice to quote environment variables when they are used as arguments in shell commands. The variable ${INPUTS_A2A_PACKAGE_NAME} should be enclosed in double quotes.
npm dist-tag rm "${INPUTS_A2A_PACKAGE_NAME}" false --silent| run: |- | ||
| npm run build:sandbox -- \ | ||
| --image google/gemini-cli-sandbox:${{ steps.image_tag.outputs.FINAL_TAG }} \ | ||
| --image google/gemini-cli-sandbox:${STEPS_IMAGE_TAG_OUTPUTS_FINAL_TAG} \ |
| working-directory: '${{ inputs.working-directory }}' | ||
| run: | | ||
| npm dist-tag add ${{ inputs.core-package-name }}@${{ inputs.version }} ${{ inputs.channel }} | ||
| npm dist-tag add ${INPUTS_CORE_PACKAGE_NAME}@${INPUTS_VERSION} ${INPUTS_CHANNEL} |
There was a problem hiding this comment.
For robustness and to prevent potential shell injection issues, it's best practice to quote environment variables when they are used as arguments in shell commands. The package, version, and channel arguments should be enclosed in double quotes.
npm dist-tag add "${INPUTS_CORE_PACKAGE_NAME}@${INPUTS_VERSION}" "${INPUTS_CHANNEL}"| working-directory: '${{ inputs.working-directory }}' | ||
| run: | | ||
| npm dist-tag add ${{ inputs.cli-package-name }}@${{ inputs.version }} ${{ inputs.channel }} | ||
| npm dist-tag add ${INPUTS_CLI_PACKAGE_NAME}@${INPUTS_VERSION} ${INPUTS_CHANNEL} |
There was a problem hiding this comment.
For robustness and to prevent potential shell injection issues, it's best practice to quote environment variables when they are used as arguments in shell commands. The package, version, and channel arguments should be enclosed in double quotes.
npm dist-tag add "${INPUTS_CLI_PACKAGE_NAME}@${INPUTS_VERSION}" "${INPUTS_CHANNEL}"| working-directory: '${{ inputs.working-directory }}' | ||
| run: | | ||
| npm dist-tag add ${{ inputs.a2a-package-name }}@${{ inputs.version }} ${{ inputs.channel }} | ||
| npm dist-tag add ${INPUTS_A2A_PACKAGE_NAME}@${INPUTS_VERSION} ${INPUTS_CHANNEL} |
There was a problem hiding this comment.
For robustness and to prevent potential shell injection issues, it's best practice to quote environment variables when they are used as arguments in shell commands. The package, version, and channel arguments should be enclosed in double quotes.
npm dist-tag add "${INPUTS_A2A_PACKAGE_NAME}@${INPUTS_VERSION}" "${INPUTS_CHANNEL}"
This is a http://go/LSC run by http://go/ghss to automatically refactor your Github Actions per http://b/485167538.
This is a PR to help you upgrade to the latest standards in Github Actions.
Please merge this PR to accept the changes. NOTE: if you do not accept this PR, it may be force merged by the GHSS team. See http://b/485167538 for more details.