Deploy preview with details which data is going to be updated for each file changed (similar to terraform plan command)

[sir-alex]

Affected Components

• [X] CLI
• [ ] Create CLI
• [ ] Test
• [ ] Docs
• [ ] Examples
• [ ] Other

Notes for the Reviewer

This is my first contribution to this project. I apologize in advance if I did something not inline with the way you maintain this project. This is addressing my own ticket #993 This PR implements detailed preview for npx checkly deploy -p BEFORE: AFTER:

High scope logic explanation:

1. Retrieve the current data from the server via API.
2. Gather the data to be sent to the API.
3. Compare the differences and display them in the CLI in a format that clearly shows the current values and the proposed updates for easy understanding.

Code level explanation: This PR introduces deploy preview functionality for the alert-channel resource type only. I implemented one resource type per PR to keep the scope manageable and avoid overloading the PR with unrelated changes. The functionality can be easily extended to support other resource types, providing similar previews.

Since this feature doesn’t alter the logic for sending data to the server, it shouldn’t break any existing functionality. It can be safely merged into the main branch. However, I recommend testing it thoroughly, as there’s always a chance I might have missed something.

Tests: Units/integration

Resolves #993

Development and Testing Approach:

I developed and tested this functionality locally using a TDD approach with the following tools:

• Verdaccio for a local npm registry
• MSW and a local mock server for API simulations

For this PR, I removed these development dependencies, as they might not align with your preferred tech stack for TDD. Additionally, updates to the testing stack should be handled in separate PRs.

If you’re interested in adding an end-to-end (e2e) testing flow to test commands in a local npm registry environment, let me know! I’d be happy to collaborate on integrating this into a testing environment.

[sorccu]

Hey @sir-alex, wow, thanks, this is very cool! Let me take some time to try it out and see if there's anything to change. I should be able to get back to you early next week at the very latest.

I would also be interested in the e2e testing environment you mentioned. It is indeed something that I would like to have in place. However, as you said, let's take things step by step. Really appreciate that you've tried to keep the PR small and reviewable.

[jasonyic]

any ETA for this PR to be reviewed and merged? this is a great feature to have, easier to identify the unchanged and updated. thanks

[sorccu]

While the intention behind the PR is great, and the code is clean as well, it still has to live at the mercy of the limitations of our API. There are unfortunately some differences in the payloads between the endpoint(s) the CLI uses and the public API, and the current implementation will need extra work each time an additional resource type is added. Again, this is not the fault of the PR at all.

This feature needs proper backend support with a preview API that allows the CLI to retrieve all changes in one go.