Skip to content

fix: Skip E3700 first-stage check for conditional stage entries - #4701

Merged
kddejong merged 2 commits into
aws-cloudformation:mainfrom
kddejong:fix/issue/4672
Sep 10, 2026
Merged

kddejong merged 2 commits into
aws-cloudformation:mainfrom
kddejong:fix/issue/4672

Conversation

@kddejong

Copy link
Copy Markdown
Contributor

Fixes #4672

Problem

E3700 treats a stage's index in the Stages list as its order. When a Stages entry is an Fn::If that can resolve to AWS::NoValue, index and realized order diverge: once an earlier conditional stage collapses to NoValue, a later conditional source stage becomes the first realized stage but still carries a non-zero list index. _is_first_stage returned False for it and the Source category was rejected — a false positive.

The runtime path for a conditional stage entry is Stages / <index> / Fn::If / <branch> / Actions / ... (the list index precedes Fn::If), so the old loop returned on the index before accounting for the condition.

Fix

When a stage's list index is immediately followed by Fn::If in the path, the entry is conditional and its realized order can't be inferred, so _is_first_stage now returns None (no determination), per the reporter's suggestion. Plain stages and whole-list Fn::If wrappers (Stages / Fn::If / branch / index) are unchanged, preserving existing true positives.

Testing

  • Added two unit cases for conditional stage entries at index 0 and index 1.
  • Existing E3700 unit tests and the codepipeline suite pass (37 passed).
  • Repro template from the issue now lints clean; the existing bad fixture (plain second-stage Source) still flags E3700.

A CodePipeline Stages entry can be an Fn::If that resolves to
AWS::NoValue. When earlier entries collapse to NoValue, a stage's list
index no longer reflects its realized order, so _is_first_stage
misclassified a conditional source stage past index 0 and E3700 fired a
false positive on its 'Source' category.

Return None (no determination) when a stage's index is immediately
followed by an Fn::If in the path, since the order can't be inferred.
Plain stages and whole-list Fn::If wrappers are unaffected.

aws-cloudformation#4672
deque elements are typed Any, so 'return path[i] == 0' returned Any from
a function declared to return bool | None. Wrap in bool().
@codecov

codecov Bot commented Sep 10, 2026 •

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 94.66%. Comparing base (5caad1e) to head (5ee672d).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files
@@           Coverage Diff           @@
##             main    #4701   +/-   ##
=======================================
  Coverage   94.66%   94.66%           
=======================================
  Files         434      434           
  Lines       15561    15561           
  Branches     3019     3019           
=======================================
  Hits        14731    14731           
  Misses        453      453           
  Partials      377      377           
Flag Coverage Δ
unittests 94.66% <100.00%> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@kddejong
kddejong merged commit eeea1a7 into aws-cloudformation:main Sep 10, 2026
21 checks passed
@kddejong
kddejong deleted the fix/issue/4672 branch September 10, 2026 23:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

E3700 false positive when Stages entries are Fn::If with AWS::NoValue

1 participant