Jinja Errors in Stack Configs do not show the Stack Name in the Error Message #1267

X-Guardian · 2022-11-28T13:15:54Z

Subject of the issue

If your Sceptre stack configs contain a Jinja error (referencing a non-existing Jinja variable is a typical scenario we have), then the error message on stack launch does not contain details of the stack config containing the error. This is particularly annoying when there is a large dependency tree on the stack that is being launched, and the Jinja error is deep within the tree.

Your environment

version of sceptre 3.2.0
version of python 3.8.8
which OS/distro: Windows 10

Steps to reproduce

dev/config.yaml

foo: bar

dev/stack.yaml

template:
  path: template1.yaml
parameters:
  Parm1: {{ foo2 }}

Expected behaviour

The error message should contain details of the config file containing the Jinja error, i.e.

"dev/stack.yaml - 'foo2' is undefined"

Actual behaviour

Only the Jinja error is currently output, i.e.

"'foo2' is undefined"

Solution

I am happy to raise a PR to improve this error message.

The text was updated successfully, but these errors were encountered:

jfalkenstein · 2022-11-28T15:48:03Z

@X-Guardian, I believe you can show the whole stacktrace if you run Sceptre with the --debug flag. Can you try that and see if that resolves your issue?

X-Guardian · 2022-11-28T16:03:41Z

--debug does show the stack name, along with potentially a lot of redundant debug output, especially for a large dependency tree. I don't feel users should need to see all this debug output just to get the name of the config file that contains the Jinja error.

jfalkenstein · 2022-11-28T16:28:23Z

I see your point there. Especially for simple ones. A PR to fix it would definitely be welcome. I agree adding the stack name would make the output better in those cases.

…ude the Stack Name (#1269) Improves the stack config Jinja error message to include the stack name. ### Original Error Message ``` 'foo2' is undefined ``` ### New Error Message ``` dev/stack.yaml - 'foo2' is undefined ```

…to include the Stack Name (Sceptre#1269) Improves the stack config Jinja error message to include the stack name. ### Original Error Message ``` 'foo2' is undefined ``` ### New Error Message ``` dev/stack.yaml - 'foo2' is undefined ```

## 4.0.0 (2023.02.08) ### Added - [Resolve #1283] Introducing `sceptre_role`, `cloudformation_service_role` (#1295) - These are just iam_role and role_arn renamed to be a lot clearer. See "Deprecations" below. ### Changed - [Resolve #1299] Making the ConnectionManager a more "friendly" interface for hooks, resolvers, and template handlers (#1287, #1300) - This creates adds the public `get_session()` and `create_session_environment_variables()` methods to make AWS interactions easier and more consistent with individual stack configurations for iam_role, profile, and region configurations. - The `call()` method now properly distinguishes between default stack configurations for profile, region, and `sceptre_role` and setting those to `None` to nullify them. - Preventing Duplicate Deprecation Warnings from being emitted (#1297) #### _Potentially_ Breaking Changes - The !cmd hook now invokes the passed command using the AWS environment variables that correspond with the stack's IAM configurations (i.e. iam_role, profile, region). This means that the hook will operate the same as every other part of Sceptre and regard how the stack is configured. This should make it easier to invoke other tools like AWS CLI with your hooks. However, if your project is setting environment variables with the intent to change how the command authenticates with AWS (such as a different token, profile, or region), these environment variables will be overridden. To maintain the same functionality, you should prefix your command with `export AWS_SESSION_TOKEN={{environment_variable.AWS_SESSION_TOKEN}} &&` (or whatever other environment variable(s) you need to explicitly set). ### Deprecations - [Resolve #1283] Deprecating `iam_role`, `role_arn`, and `template_path` (#1295) - `iam_role` and `role_arn` have been aliased to `sceptre_role` and `cloudformation_service_role`. Using these fields will result in a DeprecationWarning. - `template_path` has actually been slated for removal since v2.7. `template` should be used instead. Using `template_path` will result in a DeprecationWarning. - All three deprecated StackConfig fields will be removed in v5.0.0. ## 3.3.0 (2023.02.06) ### Added - [Resolve #1261] Add coloured differ (#1260) - Implements coloured diffs for the diff (difflib) command. Responds to --no-color. - [Resolves #1271] Extend stack colourer to include "IMPORT" states (#1272) - [Resolves #1179] cloudformation disable-rollback option (#1282) - Allow user to disable a cloudformation rollback on a sceptre deployment. ### Changed - [Resolve #1098] Deploy docker container to sceptreorg repo (#1265) - Deploy sceptre docker images to dockerhub sceptreorg repo instead of cloudreach repo - Updating Setuptools and wheel versions to avert security issues - [Resolve #1293] Improve the Stack Config Jinja Syntax Error Message to include the Stack Name (#1294) - [Resolves #1267] Improve the Stack Config Jinja Error Message to include the Stack Name (#1269) ### Fixed - [Resolve #1273] Events start from response time (#1275) - Resolves #1273 by starting event filtering from the timestamp returned in the AWS response headers rather than relying on the workstation clock. - [Resolve #1253] Failed downloads raise error (#1277) - Throwing an informative error when the template fails to download instead of passing the error message to CloudFormation. - [Resolves #1179] Changed disable-rollback default to None (#1288) - We want the default value to be None to represent "Do whatever's configured in the StackConfig" and True/False will override the StackConfig. ### Nonfunctional - Add tweet-release to CircleCI config (#1259) - [Resolves #1276] Adopt Black Auto-formatter (#1278) - Reformatting all Python files using the Black code formatter. This also delivers a new function for generating `__repr__` methods which was needed to deal with a line-too-long issue in Template. Per discussion in #1276 this PR also disables E203 in flake8. - Update sceptre-circleci docker image (#1284) - Update to build and test with a docker image that's based on the official circleci python docker image. - [Resolve #1264] Updating the CDK docs to point to the new sceptre-cdk-handler (#1285) - This updates our docs to no longer reference the old CDK approach (which didn't work with CDK assets). In its place, it references the new sceptre-cdk-handler package that covers that functionality.

X-Guardian mentioned this issue Nov 28, 2022

[Resolves #1267] Improve the Stack Config Jinja Error Message to include the Stack Name #1269

Merged

9 tasks

jfalkenstein closed this as completed in #1269 Jan 20, 2023

dboitnot mentioned this issue Feb 13, 2023

All errors related to a specific stack should include the stack name in the error message. #1306

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Jinja Errors in Stack Configs do not show the Stack Name in the Error Message #1267

Jinja Errors in Stack Configs do not show the Stack Name in the Error Message #1267

X-Guardian commented Nov 28, 2022 •

edited

Loading

jfalkenstein commented Nov 28, 2022

X-Guardian commented Nov 28, 2022

jfalkenstein commented Nov 28, 2022

Jinja Errors in Stack Configs do not show the Stack Name in the Error Message #1267

Jinja Errors in Stack Configs do not show the Stack Name in the Error Message #1267

Comments

X-Guardian commented Nov 28, 2022 • edited Loading

Subject of the issue

Your environment

Steps to reproduce

Expected behaviour

Actual behaviour

Solution

jfalkenstein commented Nov 28, 2022

X-Guardian commented Nov 28, 2022

jfalkenstein commented Nov 28, 2022

X-Guardian commented Nov 28, 2022 •

edited

Loading