Conversation
(portal deviates from this approach)
There was a problem hiding this comment.
Pull request overview
This PR fixes a bug in the Kubernetes deployment workflow where the git add command used a hardcoded path that didn't match the actual file being modified. The change makes the workflow more flexible to support different deployment repository structures.
Changes:
- Changed
git add ".chart/$ENV/values.yaml"togit add .to support dynamic file paths rather than a hardcoded structure
| git config user.email "$GIT_USER_EMAIL" | ||
| git config user.name "$GIT_USER_NAME" | ||
| git add ".chart/$ENV/values.yaml" | ||
| git add . |
There was a problem hiding this comment.
Spelling error in PR title: "dedicatd" should be "dedicated"
| git config user.email "$GIT_USER_EMAIL" | ||
| git config user.name "$GIT_USER_NAME" | ||
| git add ".chart/$ENV/values.yaml" | ||
| git add . |
There was a problem hiding this comment.
Using git add . adds all modified files in the remote directory, which is more flexible than the previous hardcoded path but less explicit. Consider the following:
- The commit message on line 205 specifically mentions "set $ENV image tag to $VERSION", which may not accurately describe all changes if multiple files are modified
- While the change fixes the mismatch between the hardcoded path and the actual file being modified (line 193), using
git add .could inadvertently commit unintended files if the workflow is modified in the future to create additional temporary files
If this flexibility is intentional to support different deployment structures (as suggested by the PR description), consider updating the commit message to be more generic, or adding a comment explaining why all files are being added rather than just the modified values.yaml file.
portal deviates from this approach