@codyswann/lisa 4.79.0 → 4.79.2

package/plugins/src/base/scripts/install-remote-agent-aws.mjs

@@ -335,9 +335,11 @@ a name carrying the owner prevents it.
 
 \`default\` is the one name that cannot be namespaced. The setup script writes
 it for this project only when nothing else already owns it; if another Lisa
-project or the operator's own configuration holds it, the script stops and says
-so rather than repointing every unqualified \`aws\` command. Pass
-\`LISA_AWS_CLAIM_DEFAULT_PROFILE=1\` to take it over deliberately.
+project or the operator's own configuration holds it, the script still writes
+every named profile and verifies them as a normal run would, leaves
+\`[default]\` untouched, and exits non-zero saying so rather than repointing
+every unqualified \`aws\` command. Use the named profiles it lists, or pass
+\`LISA_AWS_CLAIM_DEFAULT_PROFILE=1\` to take \`[default]\` over deliberately.
 
 Production and shared profiles are observer-only. Production repair remains a
 human-driven local-workstation operation.

package/plugins/src/base/scripts/remote-agent-aws-setup.sh

@@ -598,12 +598,22 @@ if [ -n "$legacy_sections" ]; then
   fi
 fi
 
+# Decided here, enforced at the end. Refusing `[default]` must not also refuse
+# the named profiles: they are namespaced, carry no collision risk, and are the
+# remedy the refusal points the operator at. Refusing before writing them told
+# the operator to use profiles that did not exist, leaving the takeover override
+# as the only real path — the outcome this guard exists to discourage. So every
+# named profile is written and verified first, `[default]` alone is left
+# untouched, and the run still exits non-zero: what the operator asked for
+# (a ready workstation with this project's default) did not happen, and a
+# caller that continued on success would run unqualified `aws` commands in the
+# operator's account believing they reached this project's.
 default_owner="$(default_profile_owner)"
+claim_default=1
 case "$default_owner" in
   ours | legacy | unclaimed) ;;
   *)
-    [ "${LISA_AWS_CLAIM_DEFAULT_PROFILE:-0}" = "1" ] || fail \
-      "refusing to overwrite the [default] AWS profile in ${config_file}: it belongs to ${default_owner}, not to ${PROFILE_NAMESPACE}. Overwriting it would silently repoint every unqualified aws command at this project's accounts. Use the named profiles instead (${profile_names}), or set LISA_AWS_CLAIM_DEFAULT_PROFILE=1 to take it over deliberately."
+    [ "${LISA_AWS_CLAIM_DEFAULT_PROFILE:-0}" = "1" ] || claim_default=0
     ;;
 esac
 
@@ -629,11 +639,13 @@ while IFS="$(printf '\t')" read -r stage role_arn region; do
 done < <(printf '%s' "$profiles_json" | jq -r 'to_entries[] | [.key, .value.roleArn, .value.region] | @tsv')
 
 default_profile="${PROFILE_NAMESPACE}-agent-${default_stage}"
-aws configure set role_arn "$default_role_arn" --profile default
-aws configure set source_profile "$BOOTSTRAP_PROFILE" --profile default
-aws configure set external_id "$external_id" --profile default
-aws configure set role_session_name "$session_name" --profile default
-aws configure set region "$default_region" --profile default
+if [ "$claim_default" = "1" ]; then
+  aws configure set role_arn "$default_role_arn" --profile default
+  aws configure set source_profile "$BOOTSTRAP_PROFILE" --profile default
+  aws configure set external_id "$external_id" --profile default
+  aws configure set role_session_name "$session_name" --profile default
+  aws configure set region "$default_region" --profile default
+fi
 
 chmod 600 "$credentials_file" "$config_file"
 
@@ -674,4 +686,26 @@ if [ -n "$legacy_names" ]; then
   fi
 fi
 
+if [ "$claim_default" = "0" ]; then
+  if [ "${LISA_AWS_SKIP_VERIFY:-0}" = "1" ]; then
+    named_state="were written but not verified (LISA_AWS_SKIP_VERIFY=1)"
+  elif [ "${LISA_AWS_VERIFY_ALL_PROFILES:-0}" = "1" ]; then
+    named_state="were written and verified"
+  else
+    # Only the default stage's account is proved without VERIFY_ALL, so the
+    # message names exactly that one rather than vouching for all of them.
+    named_state="were written; ${default_profile} was verified (set LISA_AWS_VERIFY_ALL_PROFILES=1 to verify every one)"
+  fi
+  # The trap the override walks into when `[default]` is static keys rather
+  # than a config-side profile: claiming rewrites only the config file, so the
+  # keys stay, and `[default]` ends up holding a role and an unrelated account's
+  # keys at once. Which wins depends on each tool's credential precedence. The
+  # key material itself is never echoed.
+  static_keys_note=""
+  if [ -n "$(profile_setting_value "$credentials_file" "default" "aws_access_key_id")" ]; then
+    static_keys_note=" Note: ${credentials_file} holds long-lived access keys under [default]. Claiming rewrites only ${config_file} and does not remove them, so [default] would carry both this project's role and those keys, and which one a tool uses depends on its credential precedence."
+  fi
+  fail "refusing to overwrite the [default] AWS profile in ${config_file}: it belongs to ${default_owner}, not to ${PROFILE_NAMESPACE}. Overwriting it would silently repoint every unqualified aws command at this project's accounts. [default] was left untouched; this project's named profiles ${named_state} (${profile_names}). Use them instead, for example AWS_PROFILE=${default_profile} or --profile ${default_profile}, or set LISA_AWS_CLAIM_DEFAULT_PROFILE=1 to take [default] over deliberately.${static_keys_note}"
+fi
+
 echo "remote-agent-aws-setup: ready (${session_name}; namespace=${PROFILE_NAMESPACE} via ${namespace_source}; default=${default_profile} in account ${default_expected_account}; profiles=${profile_names})"

package/plugins/src/base/skills/lisa-setup-remote-aws/SKILL.md

@@ -53,8 +53,13 @@ two bundles declaring the same stages overwrite each other in the shared
 malformed. The name is the only place the owner can be recorded.
 
 `default` cannot be namespaced. The script claims it only when nothing else
-owns it, and otherwise stops and names the current owner;
-`LISA_AWS_CLAIM_DEFAULT_PROFILE=1` takes it over deliberately.
+owns it. Otherwise it still writes every named profile and verifies them as a
+normal run would (the default stage, or every stage under
+`LISA_AWS_VERIFY_ALL_PROFILES=1`), leaves `[default]` untouched, and exits
+non-zero naming the current owner and the named profiles to use instead (for example `AWS_PROFILE=<project>-agent-dev`);
+`LISA_AWS_CLAIM_DEFAULT_PROFILE=1` takes `[default]` over deliberately. When the
+owner is long-lived keys under `[default]` in `~/.aws/credentials`, the message
+also says that claiming would not remove them.
 
 Readiness is an account check, not a liveness check. `sts:GetCallerIdentity`
 succeeding proves the credentials work, not that they reached the intended

package/typescript/copy-overwrite/.github/GITHUB_ACTIONS.md

@@ -584,25 +584,40 @@ mutually exclusive:
 
 ```yaml
 with:
-  # A template. {version} is required; {tag}, {sha} (the commit that
-  # triggered the run) and {release_commit} (the commit the release cut) are
-  # optional. {sha:N} and {release_commit:N} keep the first N (7-40) characters.
-  sentry_release_name: 'my-app@{version}+0.{sha:8}'
+  # A template. It must use {version} (the released version) or
+  # {sha_version} (the package.json version at the commit that triggered the
+  # run); {tag}, {sha} (the commit that triggered the run) and
+  # {release_commit} (the commit the release cut) are optional.
+  # {sha:N} and {release_commit:N} keep the first N (7-40) characters.
+  sentry_release_name: 'my-app@{sha_version}+0.{sha:8}'
 ```
 
+**`{version}` or `{sha_version}`?** Use the one your deployed build reports.
+`release.yml` builds from the commit that triggered the run, then commits the
+version bump afterwards with `[skip ci]`, and that bump is never built. So an
+app that reads its version from `package.json` at build time reports the
+version *before* the bump: a run triggered by a commit whose `package.json`
+says `0.0.674` releases `0.0.675`, but the app reports `0.0.674`. Such an app
+needs `{sha_version}`; `{version}` would name a release no event ever reports.
+`{sha_version}` is read from `package.json` at the triggering commit, and the
+job fails if that file is missing, is not valid JSON, or has no semver
+`version`.
+
 ```yaml
 with:
   # A command, for identifiers a template cannot express (for example a build
   # number derived from the version). It runs in the checked-out repository
   # before any dependency install, receives SENTRY_RELEASE_VERSION,
-  # SENTRY_RELEASE_TAG, SENTRY_RELEASE_SHA and SENTRY_RELEASE_COMMIT, gets no
-  # Sentry credential, and prints the name on stdout.
+  # SENTRY_RELEASE_TAG, SENTRY_RELEASE_SHA, SENTRY_RELEASE_COMMIT and
+  # SENTRY_RELEASE_SHA_VERSION (empty when package.json at the triggering
+  # commit has no usable version), gets no Sentry credential, and prints the
+  # name on stdout.
   sentry_release_name_command: 'node scripts/print-sentry-release.mjs'
 ```
 
 Point the command at the same code the app uses to compute its release, so the
-two cannot drift apart. The resolved name must contain the released version,
-be printable ASCII without whitespace, `/` or `\`, and be at most 200
+two cannot drift apart. The resolved name must contain the released version
+or the triggering commit's `package.json` version, be printable ASCII without whitespace, `/` or `\`, and be at most 200
 characters. A name that cannot be resolved **fails the Sentry job** rather than
 falling back to the bare version, because a release no event reports is
 silently useless. The resolved name is published as the workflow output