Wizard: Fix blueprint name update on Architecture/Distribution changes (HMS-5556)

[mgold1234]

This commit resolves an issue where the blueprint name did not update when the user changed the Architecture or Distribution.
Additionally, it sets an initial value for blueprintName in the WizardSlice.

FIX ISSUE: #2929

JIRA: HMS-5556

[mgold1234]

/jira-epic HMS-5294

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 85.19%. Comparing base (716c0bf) to head (84b219b).

@@            Coverage Diff             @@
##             main    #2936      +/-   ##
==========================================
- Coverage   85.19%   85.19%   -0.01%     
==========================================
  Files         167      167              
  Lines       20904    20901       -3     
  Branches     2104     2103       -1     
==========================================
- Hits        17810    17807       -3     
  Misses       3076     3076              
  Partials       18       18              

Files with missing lines	Coverage Δ
...mponents/CreateImageWizard/steps/Details/index.tsx	100.00% <100.00%> (ø)
...ents/CreateImageWizard/steps/ImageOutput/index.tsx	100.00% <100.00%> (ø)
...omponents/CreateImageWizard/steps/Review/index.tsx	100.00% <ø> (ø)
...nents/CreateImageWizard/utilities/requestMapper.ts	95.20% <100.00%> (+<0.01%)	⬆️
...ateImageWizard/utilities/useGenerateDefaultName.ts	100.00% <100.00%> (ø)

---

Continue to review full report in Codecov by Sentry.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 716c0bf...84b219b. Read the comment docs.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[regexowl]

Thanks for working on fixing this, works really nicely! ❤️

If we populate default name on Image Output step, we can probably get rid of useGenerateDefaultName() on Details and Review steps.

Could you also please add two tests? One to check the name gets updated with changes and second to check that custom blueprint name doesn't get overwritten.

[mgold1234]

@regexowl Thank you for your comments. I didn’t remove it from the Details and Review steps because sometimes, when a user opens the Review step for the first time, the blueprint name doesn’t update. Keeping it prevents this issue from happening.

Screen.Recording.2025-03-09.at.19.11.31.mov

[regexowl]

I see, the name is not populated until the release/arch are changed. Wouldn't that be a bug though? I mean depends on the scope of this PR, but we could both populate and update the name on the Image Output step.

[mgold1234]

@regexowl The name is populated when there is a value in the release/architecture, not just after it's populated. However, there is sometimes a delay, causing the blueprint not to update consistently on the first render. I explored several solutions, and I found that limiting the name generation to the Review step — and removing it from the Details step — resolves the issue with the initial render.
wdyt?

[regexowl]

I'm not sure I get it. This way if you click through to the Details step the Blueprint name is empty, but we still allow the user to proceed. Which I think is not really what we want as the empty Blueprint name input should be invalid and block the "Next" button, right?

I've tried to follow through updating of the blueprint name on the Image output step. The hook seems to be triggered correctly, but what I'd guess is happening is that the blueprintName initial value (which is an empty string) overrides the default name that gets generated before it. What if we set the proper default name as an initial value? We already have a function we could use for that and default release and arch are also set.

[mgold1234]

need to update ':test_blueprint_import' in iqe_test

[regexowl]

need to update ':test_blueprint_import' in iqe_test

Based on the error in IQE tests, this looks like we're overwriting a custom name with the changes. Which shouldn't be the case 🤔

[mgold1234]

the IQE TEST found real bug :)
I updated the flag of isCustomName to True in the correct place, now all tests should pass

[mgold1234]

@regexowl yesterday I checked the import scenario by mistake in a different pr, and it was working good, so I thought I miss something in the IQE test :)
thank you for pointing this out