Stop showing apps as deleted when adding ignore

[drewbailey]

When adding argocd-diff-preview/ignore annotation on the target branch, apps were incorrectly shown as "deleted" because they still existed on the base branch without the annotation.

• Track apps filtered by ignore annotation separately from other filters
• Filter ignored apps from base branch before diff comparison
• Use composite key (ID + FileName) to match apps, preventing false positives when multiple ApplicationSets generate apps with same name
• Process target branch first to collect ignored apps list

This fix applies to both direct Applications and Applications generated from ApplicationSets.

[dag-andersen]

Thank you so much for your interest in the project!
Sorry for the delayed reply on the PR. I'm on vacation until December 20th. I'll review it as soon as I'm back 🚀

[dag-andersen]

@drewbailey
Thank you so much for the time an effort you put into this.

I understand the problem you are trying to solve. This has been a challenge since the beginning of this project. Adding any kind of filter that "de-selects" an application makes it look like the application is being deleted in the diff, which is confusing. This is really a general problem with all filtering mechanisms, and I would like to avoid writing a separate solution for each one.

I am not sure what the best approach is here.

My suggestion is that we solve this in a more generic way. I was thinking about something like this:

• Render an Application if it is selected by EITHER the base or the target branch.
• An application is only skipped if both branches are skipping it.

Or the other way around...

• Skip rendering an Application on both branches if either of them skips it.

I have a proof of concept here: [link]. It required reworking the structure a bit.

...

However, the main issue I see with both your implementation and mine is that the "key" we generate is based on name + filename + etc....

The problem is that this can easily lead to confusion. Users often create PR's where they add a filtering mechanism and also move or rename files, and in those cases the filtering system can break.

I worry that it is not always obvious why the filtering sometimes "just works" when a filter is added, and other times does not - simply because other changes were made in the same PR. This type of Inconsistent make users loose trust in the tool.

...

That said, I had a new idea that might make it clearer what is going on when people add filtering mechanisms.

The diff could show how many applications are being skipped on each branch.

That way, even if an application looks like it was deleted as part of a PR, the user can also see that an additional application is now being skipped.

What do you think? 😄 Curious to hear if this reasoning makes sense to you

[drewbailey]

Thanks for the review, I agree the compound key approach probably isn't the right approach for the reasons you outlined.

Or the other way around...

Skip rendering an Application on both branches if either of them skips it.

This is more along the lines of what I was thinking, though I was thinking to use the target branch more authoritatively, I think this is the decision table I'm after.

Base has ignore annotation	Target has ignore annotation	Todays behavior	Desired Behavior
No	No	Render normal diff	Render normal diff
Yes	No	Base filtered; app shows as added in target	Render normal diff (target authoritative; do not ignore)
No	Yes	Target filtered; app shows as deleted in target	Omit (ignore both)
Yes	Yes	Omit (ignore both)	Omit (ignore both)