Bump version to 0.3.1-SNAPSHOT and update documentation #468

rohitkumarbhagat · 2026-01-27T15:14:23Z

This PR bumps the project version to 0.3.1-SNAPSHOT, updates build scripts to support dynamic JAR discovery, and improves release documentation.

gemini-code-assist · 2026-01-27T15:14:47Z

Summary of Changes

Hello @rohitkumarbhagat, I'm Gemini Code Assist¹! 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 advances the project's development lifecycle by updating its internal version to "0.3.1-SNAPSHOT". It significantly improves the build and deployment reliability by implementing dynamic JAR file discovery in various CI/CD scripts, eliminating dependencies on hardcoded version strings. Additionally, the project's README.md has been enhanced with clearer instructions for building and running artifacts, and a new guide for the release process.

Highlights

Version Update: The project's snapshot version has been updated from "0.1-SNAPSHOT" to "0.3.1-SNAPSHOT" in the pom.xml.
Dynamic JAR Discovery in Build Scripts: Build scripts across cloudbuild.yaml, pipeline/differ/template.sh, pipeline/ingestion/cloudbuild.yaml, and pipeline/ingestion/template.sh have been modified to use wildcards for discovering JAR files. This removes hardcoded version numbers, making the build process more robust and less prone to errors when versions change.
Enhanced Documentation: The README.md has been updated to use generic version placeholders for JAR file names in build instructions and now includes a new, detailed section outlining the steps for "Creating a Release".

Using Gemini Code Assist

The 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 /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	`/gemini review`	Performs a code review for the current pull request in its current state.
Pull Request Summary	`/gemini summary`	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	`/gemini help`	Displays a list of available commands.

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 .gemini/ folder in the base of the repository. Detailed instructions can be found here.

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.

Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

gemini-code-assist

Code Review

This pull request updates the project version and build scripts to dynamically discover JAR files, avoiding hardcoded versions, and updates documentation. While this improves flexibility, it introduces a command injection vulnerability in pipeline/ingestion/cloudbuild.yaml due to the insecure use of Cloud Build substitutions within a bash -c block. Furthermore, the current implementation for finding the JAR file using ls | head -n 1 is not robust and could lead to deploying an older artifact if the build directory isn't clean.

gemini-code-assist · 2026-01-27T15:17:25Z

pipeline/ingestion/cloudbuild.yaml

+          gs://$_TEMPLATE_BUCKET/templates/flex/ingestion.json \
+          --image-gcr-path "${_IMAGE_GCR_PATH}:$SHORT_SHA" \


This section introduces a command injection vulnerability due to the insecure use of Cloud Build substitutions ($_TEMPLATE_BUCKET, ${_IMAGE_GCR_PATH}) within a bash -c block. Cloud Build performs string replacement before passing the script to the shell, which can lead to command injection if an attacker can influence these substitutions. Specifically, on line 32, $_TEMPLATE_BUCKET is unquoted, allowing command breakout, and on line 33, ${_IMAGE_GCR_PATH} inside double quotes still allows command substitution (e.g., $(id)). To remediate this, pass the substitutions as environment variables to the build step and use them within the shell script using shell variable expansion (e.g., "$${TEMPLATE_BUCKET}").

Any thoughts on this?

gemini-code-assist · 2026-01-27T15:17:26Z

cloudbuild.yaml

+        # Find the JAR file using wildcard
+        JAR_FILE=$(ls tool/target/datacommons-import-tool-*-jar-with-dependencies.jar | head -n 1)
+        echo "Found JAR: ${JAR_FILE}"
+        gsutil cp "${JAR_FILE}" "gs://datacommons_public/import_tools/import-tool.jar"


The use of ls ... | head -n 1 to find the JAR file is not robust. If the build directory is not clean, multiple JAR files with different versions might exist. ls sorts alphabetically, so this command could select an older version, leading to the deployment of an incorrect artifact. A safer approach is to ensure that exactly one JAR file matches the pattern and fail the build otherwise.

# Find the JAR file, ensuring there is exactly one. JAR_FILES=(tool/target/datacommons-import-tool-*-jar-with-dependencies.jar) if [ "${#JAR_FILES[@]}" -ne 1 ]; then echo "Error: Expected 1 JAR file, but found ${#JAR_FILES[@]}. Aborting." >&2 exit 1 fi JAR_FILE="${JAR_FILES[0]}" echo "Found JAR: ${JAR_FILE}" gsutil cp "${JAR_FILE}" "gs://datacommons_public/import_tools/import-tool.jar"

Can we consider passing the version as a substitution variable (similar to API key)?

gemini-code-assist · 2026-01-27T15:17:26Z

pipeline/differ/template.sh

+    # Find the JAR file using wildcard
+    JAR_FILE=$(ls target/differ-bundled-*.jar | head -n 1)
+    echo "Found JAR: ${JAR_FILE}"


The use of ls ... | head -n 1 to find the JAR file is not robust. If the build directory is not clean, multiple JAR files with different versions might exist. ls sorts alphabetically, so this command could select an older version. A safer approach is to ensure that exactly one JAR file matches the pattern.

Suggested change

# Find the JAR file using wildcard

JAR_FILE=$(ls target/differ-bundled-*.jar | head -n 1)

echo "Found JAR: ${JAR_FILE}"

# Find the JAR file, ensuring there is exactly one.

JAR_FILES=(target/differ-bundled-*.jar)

if [ "${#JAR_FILES[@]}" -ne 1 ]; then

echo "Error: Expected 1 JAR file, but found ${#JAR_FILES[@]}. Aborting." >&2

exit 1

fi

JAR_FILE="${JAR_FILES[0]}"

echo "Found JAR: ${JAR_FILE}"

gemini-code-assist · 2026-01-27T15:17:26Z

pipeline/ingestion/template.sh

+    # Find the JAR file using wildcard
+    JAR_FILE=$(ls target/ingestion-bundled-*.jar | head -n 1)
+    echo "Found JAR: ${JAR_FILE}"


The use of ls ... | head -n 1 to find the JAR file is not robust. If the build directory is not clean, multiple JAR files with different versions might exist. ls sorts alphabetically, so this command could select an older version. A safer approach is to ensure that exactly one JAR file matches the pattern.

Suggested change

# Find the JAR file using wildcard

JAR_FILE=$(ls target/ingestion-bundled-*.jar | head -n 1)

echo "Found JAR: ${JAR_FILE}"

# Find the JAR file, ensuring there is exactly one.

JAR_FILES=(target/ingestion-bundled-*.jar)

if [ "${#JAR_FILES[@]}" -ne 1 ]; then

echo "Error: Expected 1 JAR file, but found ${#JAR_FILES[@]}. Aborting." >&2

exit 1

fi

JAR_FILE="${JAR_FILES[0]}"

echo "Found JAR: ${JAR_FILE}"

vish-cs · 2026-01-28T06:50:32Z

pom.xml

        <maven.compiler.target>17</maven.compiler.target>
        <!-- Dependency versions -->
-        <revision>0.1-SNAPSHOT</revision>
+        <revision>0.3.1-SNAPSHOT</revision>


Curious why go from 0.1 to 0.3.1..shall we do 0.1.1 instead?

vish-cs · 2026-01-28T06:51:26Z

pipeline/ingestion/cloudbuild.yaml

+          gs://$_TEMPLATE_BUCKET/templates/flex/ingestion.json \
+          --image-gcr-path "${_IMAGE_GCR_PATH}:$SHORT_SHA" \


Any thoughts on this?

vish-cs · 2026-01-28T06:54:11Z

cloudbuild.yaml

+        # Find the JAR file using wildcard
+        JAR_FILE=$(ls tool/target/datacommons-import-tool-*-jar-with-dependencies.jar | head -n 1)
+        echo "Found JAR: ${JAR_FILE}"
+        gsutil cp "${JAR_FILE}" "gs://datacommons_public/import_tools/import-tool.jar"


Can we consider passing the version as a substitution variable (similar to API key)?

Bump version to 0.3.1-SNAPSHOT and update documentation

6ec7a9c

rohitkumarbhagat requested a review from vish-cs January 27, 2026 15:14

gemini-code-assist bot reviewed Jan 27, 2026

View reviewed changes

vish-cs reviewed Jan 28, 2026

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Bump version to 0.3.1-SNAPSHOT and update documentation #468

Bump version to 0.3.1-SNAPSHOT and update documentation #468

Uh oh!

rohitkumarbhagat commented Jan 27, 2026

Uh oh!

gemini-code-assist bot commented Jan 27, 2026

Uh oh!

gemini-code-assist bot left a comment

Uh oh!

gemini-code-assist bot Jan 27, 2026

Uh oh!

vish-cs Jan 28, 2026

Uh oh!

gemini-code-assist bot Jan 27, 2026

Uh oh!

vish-cs Jan 28, 2026

Uh oh!

gemini-code-assist bot Jan 27, 2026

Uh oh!

gemini-code-assist bot Jan 27, 2026

Uh oh!

vish-cs Jan 28, 2026

Uh oh!

vish-cs Jan 28, 2026

Uh oh!

vish-cs Jan 28, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

		gs://$_TEMPLATE_BUCKET/templates/flex/ingestion.json \
		--image-gcr-path "${_IMAGE_GCR_PATH}:$SHORT_SHA" \

-    # Find the JAR file using wildcard
-    JAR_FILE=$(ls target/differ-bundled-*.jar | head -n 1)
-    echo "Found JAR: ${JAR_FILE}"
+    # Find the JAR file, ensuring there is exactly one.
+    JAR_FILES=(target/differ-bundled-*.jar)
+    if [ "${#JAR_FILES[@]}" -ne 1 ]; then
+        echo "Error: Expected 1 JAR file, but found ${#JAR_FILES[@]}. Aborting." >&2
+        exit 1
+    fi
+    JAR_FILE="${JAR_FILES[0]}"
+    echo "Found JAR: ${JAR_FILE}"

Bump version to 0.3.1-SNAPSHOT and update documentation #468

Are you sure you want to change the base?

Bump version to 0.3.1-SNAPSHOT and update documentation #468

Uh oh!

Conversation

rohitkumarbhagat commented Jan 27, 2026

Uh oh!

gemini-code-assist bot commented Jan 27, 2026

Summary of Changes

Highlights

Footnotes

Uh oh!

gemini-code-assist bot left a comment

Choose a reason for hiding this comment

Code Review

Uh oh!

gemini-code-assist bot Jan 27, 2026

Choose a reason for hiding this comment

Uh oh!

vish-cs Jan 28, 2026

Choose a reason for hiding this comment

Uh oh!

gemini-code-assist bot Jan 27, 2026

Choose a reason for hiding this comment

Uh oh!

vish-cs Jan 28, 2026

Choose a reason for hiding this comment

Uh oh!

gemini-code-assist bot Jan 27, 2026

Choose a reason for hiding this comment

Uh oh!

gemini-code-assist bot Jan 27, 2026

Choose a reason for hiding this comment

Uh oh!

vish-cs Jan 28, 2026

Choose a reason for hiding this comment

Uh oh!

vish-cs Jan 28, 2026

Choose a reason for hiding this comment

Uh oh!

vish-cs Jan 28, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants