feat: add option to enable tracking annotation/label for CRDs

[cjcocokrisp]

At the current moment we do not support having the tracking label/annotation on CRDs. This makes it so some sync options do not work with CRDs. It also delays status updates for a CRD to show out of sync. In Argo CD Agent we also have an issue where CRDs are not viewable on the remote clusters due to them not having this. Not having CRDs get this seemed to be due to concerns for removal of CRDs which would cause the CRs of the CRD to also get deleted.

This PR adds in a flag to the repo server that allows for setting tracking labels on CRDs to fix the problems listed in the issue below. For concerns about deletion there is a check to see if an object is a CRD before deleting. I could also see an argument where this is not behind a flag and just the default behavior so I am curious about what people think about that.

Closes #17400

Checklist:

• Either (a) I've created an enhancement proposal and discussed it with the community, (b) this is a bug fix, or (c) this does not need to be in the release notes.
• The title of the PR states what changed and the related issues number (used for the release note).
• The title of the PR conforms to the Title of the PR
• I've included "Closes [ISSUE #]" or "Fixes [ISSUE #]" in the description to automatically close the associated issue.
• I've updated both the CLI and UI to expose my feature, or I plan to submit a second PR with them.
• [] Does this PR require documentation updates?
• I've updated documentation as required by this PR.
• [X I have signed off all my commits as required by DCO
• I have written unit and/or e2e tests for my change. PRs without these are unlikely to be merged.
• My build is green (troubleshooting builds).
• My new feature complies with the feature status guidelines.
• I have added a brief description of why this PR is necessary and/or what this PR solves.
• Optional. My organization is added to USERS.md.
• Optional. For bug fixes, I've indicated what older releases this fix should be cherry-picked into (this may or may not happen depending on risk/complexity).

[bunnyshell]

🔴 Preview Environment stopped on Bunnyshell

See: Environment Details | Pipeline Logs

Available commands (reply to this comment):

• 🔵 /bns:start to start the environment
• 🚀 /bns:deploy to redeploy the environment
• ❌ /bns:delete to remove the environment

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
⚠️ Please upload report for BASE (master@26621ad). Learn more about missing BASE report.
⚠️ Report is 27 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff            @@
##             master   #27907   +/-   ##
=========================================
  Coverage          ?   64.36%           
=========================================
  Files             ?      422           
  Lines             ?    57835           
  Branches          ?        0           
=========================================
  Hits              ?    37228           
  Misses            ?    17103           
  Partials          ?     3504           

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

[ppapapetrou76]

Please add the new config map key to docs/operator-manual/argocd-cmd-params-cm.yaml

Also I'm concerned that this is a global to the repo flag and can't be applied to some apps or projects instead.

I'd like to see what others think about it

[cjcocokrisp]

Please add the new config map key to docs/operator-manual/argocd-cmd-params-cm.yaml

Also I'm concerned that this is a global to the repo flag and can't be applied to some apps or projects instead.

I'd like to see what others think about it

Thanks for the review @ppapapetrou76. I addressed the comments.

Yeah I can see the concern. If configured at the application or project level from the argocd agent side we can tell users to include that or maybe even inject the option ourselves by default.

[ppapapetrou76]

Hey @cjcocokrisp, thanks for addressing all the feedback from the previous review —

Regarding my concern about the flag scope and to make things easier to move forward

1. Was per-app or per-project granularity considered and explicitly ruled out?
2. If this is intentionally a global flag, could you document this as a known limitation — e.g. in the feature docs or release notes?

I'd like more opinions here by @argoproj/argocd-approvers

Thanks again for the effort on this 🙏

[cjcocokrisp]

Was per-app or per-project granularity considered and explicitly ruled out?

I thought about this but then thought it might be a little bit overkill for just one resource type to go and add something to the manifest request and then a field to the app/project spec. I think it could be easily done to be more granular just wanted to go with the easier option to get some initial feedback.

If this is intentionally a global flag, could you document this as a known limitation — e.g. in the feature docs or release notes?

If we decide to go with the global flag then sure I can write something in the docs sounds good. 👍

Looking forward to hearing what others think about this.