Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cross tests for check: Investigate the need for applying TF defaults in Check #1763

Open
Tracked by #1796
VenelinMartinov opened this issue Mar 18, 2024 · 0 comments
Labels
kind/engineering Work that is not visible to an external user

Comments

@VenelinMartinov
Copy link
Contributor

VenelinMartinov commented Mar 18, 2024

What happened?

During the work on #1546, a possible discrepancy was found between how TF and the bridge handle TF-level defaults before Check.

The immediate issue was addressed there but there might be further redundancies we might be able to simplify.
Most of the TF methods don't require the TF defaults to be applied when creating the inputs.

Related to this is dealing with ConflictsWith and ExactlyOneOf in schema.go - we might be able to remove that logic if we were not applying the TF defaults.

More details: #1546 (comment)

This work will be much easier if we have a sensible framework for comparing TF to bridge behaviour.

Example

.

Output of pulumi about

.

Additional context

No response

Contributing

Vote on this issue by adding a 👍 reaction.
To contribute a fix for this issue, leave a comment (and link to your pull request, if you've opened one already).

@VenelinMartinov VenelinMartinov added needs-triage Needs attention from the triage team kind/bug Some behavior is incorrect or out of spec labels Mar 18, 2024
@iwahbe iwahbe removed the needs-triage Needs attention from the triage team label Mar 25, 2024
@mjeffryes mjeffryes changed the title Investigate the need for applying TF defaults in Check Cross tests for check: Investigate the need for applying TF defaults in Check Mar 26, 2024
@mjeffryes mjeffryes added kind/engineering Work that is not visible to an external user and removed kind/bug Some behavior is incorrect or out of spec labels Mar 26, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/engineering Work that is not visible to an external user
Projects
None yet
Development

No branches or pull requests

3 participants