You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
ENABLE_MODEL_ARMOR_FLAG is only ever assigned inside the FEDRAMP_HIGH/NONE branch, but it's read unconditionally a few lines later as --argjson model_armor "\$ENABLE_MODEL_ARMOR_FLAG". Under IL4 or IL5 the branch never runs, jq is handed an empty argument, and since the script runs under set -e it aborts right there — after the operator has already answered every other prompt in the app loop.
Initialised it to false just before the gate. Doing it inside the loop rather than once at the top also means a previous app's answer can't leak into the next iteration, which would have been a quieter version of the same bug.
This is the same code path #179 touches from the other side — that one is about option 4 leaving the regime empty; this is about IL4/IL5, which stay broken regardless of that fix.
…gate
The only two assignments were inside the FEDRAMP_HIGH/NONE branch, but the
value is consumed unconditionally by jq --argjson. Under IL4/IL5 the variable
was unset, so jq got an empty argument and set -e aborted the script part-way
through configuring applications. Initialising per iteration also stops a
previous app's answer leaking into the next one.
Fixesgoogle#177
Signed-off-by: Aloys Jehwin <aloysjehwin@gmail.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
bugSomething isn't workinggemini enterpriseGemini Enterprise (GE) relatedgemini for governmentGemini for Government (G4G) relatedLevel of Effort - LowQuick, well-defined tasks with no unknowns; takes a few hours up to one day to completePriority - HighCritical issues blocking development or users; urgent bugs or core features for release
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
ENABLE_MODEL_ARMOR_FLAGis only ever assigned inside theFEDRAMP_HIGH/NONEbranch, but it's read unconditionally a few lines later as--argjson model_armor "\$ENABLE_MODEL_ARMOR_FLAG". Under IL4 or IL5 the branch never runs, jq is handed an empty argument, and since the script runs underset -eit aborts right there — after the operator has already answered every other prompt in the app loop.Initialised it to
falsejust before the gate. Doing it inside the loop rather than once at the top also means a previous app's answer can't leak into the next iteration, which would have been a quieter version of the same bug.This is the same code path #179 touches from the other side — that one is about option 4 leaving the regime empty; this is about IL4/IL5, which stay broken regardless of that fix.
Fixes#177