feat(cli): add support for multiple sources to app diff|manifests command with revisions flag

[ishitasequeira]

The PR adds support for multiple sources to argocd app manifests and argocd app diff commands. As part of this PR, the support for multiple sources is by the addition of 2 new flags --revisions and --source-indexes. This 2 flags allow the user to set a revision for a specific source defined by index in source-indexes flag.

Examples:

1. argocd app manifests command

./dist/argocd app manifests guestbook --revisions 4171e73dec711bde9a130398d3cfc93363b16339 --source-indexes 1

2. argocd app diff command

./dist/argocd app diff guestbook --revisions 4171e73dec711bde9a130398d3cfc93363b16339 --source-indexes 1

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 Toolchain Guide
• 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.
• 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).

[pasha-codefresh]

@CodiumAI-Agent /review

[CodiumAI-Agent]

PR Review

⏱️ Estimated effort to review [1-5]	4, due to the complexity introduced by handling multiple sources and revisions, and the significant changes made across multiple files including server logic, CLI commands, and documentation. The PR touches on critical functionalities and requires careful consideration of edge cases and error handling.
🧪 Relevant tests	No
🔍 Possible issues	Possible Bug: The implementation assumes sourceIndexes start at 1, which is unconventional and might lead to off-by-one errors or confusion. Consider using zero-based indexing for consistency with common programming practices.
	Error Handling: There's a lack of detailed error messages in some new conditions, such as when source-indexes and revisions lengths do not match. Providing more context in error messages can improve the user experience and make debugging easier.
	Performance Concern: The loop that generates manifests for each source could potentially lead to performance issues for applications with a large number of sources. Consider optimizing this part of the code or documenting potential performance impacts.
🔒 Security concerns	No

Code feedback:

---

relevant file	cmd/argocd/commands/app.go
suggestion	Consider using zero-based indexing for sourceIndexes to align with common programming practices and reduce the risk of off-by-one errors. This change would involve adjusting the validation logic and documentation to reflect the zero-based approach. [important]
relevant line	errors.CheckError(fmt.Errorf("source-index cannot be less than or equal to 0. Index starts at 1."))

---

relevant file	server/application/application.go
suggestion	Optimize the loop that generates manifests for each source to handle cases with a large number of sources more efficiently. This could involve parallel processing or other optimization techniques to reduce the potential performance impact. [medium]
relevant line	for _, source := range sources {

---

relevant file	cmd/argocd/commands/app.go
suggestion	Improve error messages to provide more context, especially when the lengths of revisions and sourceIndexes do not match. This will help users understand the issue more clearly and fix their commands accordingly. [medium]
relevant line	errors.CheckError(fmt.Errorf("While using revisions and source-indexes, length of values for both flags should be same."))

---

relevant file	server/application/application.go
suggestion	Add validation to ensure that the revisionSourceMappings map does not contain invalid indexes before proceeding with the generation of manifests. This can prevent runtime errors and ensure that the mappings are correctly applied. [important]
relevant line	if q.GetRevisionSourceMappings() != nil && len(q.GetRevisionSourceMappings()) > 0 {

---

---

✨ Review tool usage guide:

---

Overview:
The review tool scans the PR code changes, and generates a PR review which includes several types of feedbacks, such as possible PR issues, security threats and relevant test in the PR. More feedbacks can be added by configuring the tool.

The tool can be triggered automatically every time a new PR is opened, or can be invoked manually by commenting on any PR.

• When commenting, to edit configurations related to the review tool (pr_reviewer section), use the following template:

/review --pr_reviewer.some_config1=... --pr_reviewer.some_config2=...

• With a configuration file, use the following template:

[pr_reviewer]
some_config1=...
some_config2=...

See the review usage page for a comprehensive guide on using this tool.

[agaudreault]

I like the input parameters, seems like a good and intuitive approach for people using multi sources

[agaudreault]

intArray type would make it clearer to users and not leak go implementation details

[ishitasequeira]

Unfortunately, this is an auto-generated document. I am using int64Slice datatype for sourceIndexes as we do not have a function to parse int[] input in flagSet.

[agaudreault]

Is that necessary in this PR? IIRC, updating this affect the kubernetes compatibility. It's probably better to update all k8s.io dependency to be in v0.29 in a dedicated PR if necessary.

[ishitasequeira]

Will revert this.

[anandf]

Should this be int64 ? I feel we can use uint or unit32 here as the index positions do not have negative numbers.

[ishitasequeira]

The command flagset does not support uint or uint32. Thus, had to keep it int or int64. Had used int64 to keep it consistent with what is needed by revisionSourceMappings. I can change this to int and then typecast it to int64 for creating revisionSourceMappings.

[anandf]

If flagset support is missing for uint, then let's stick to int64

[anandf]

LGTM

[agaudreault]

LGTM. Lets discuss the index at the next contributor meeting

[crenshaw-dev]

Can you add a Long usage description for the app manifests command to provide an example of how to use this?

I'm not sure the docs are correct about the flags being comma-delimited:

It's behaving like it's not comma-delimited but rather repeated:
dist/argocd app manifests test --revisions d7927a27b4533926b7d86b5f249cd9ebe7625e90,53e28ff20cc530b9ada2173fbbd64d48338583ba --source-indexes 1,2
FATA[0000] While using revisions and source-indexes, length of values for both flags should be same.

This seems to work:

dist/argocd app manifests test --revisions d7927a27b4533926b7d86b5f249cd9ebe7625e90 --revisions 53e28ff20cc530b9ada2173fbbd64d48338583ba --source-indexes 1 --source-indexes 2

Should we add an e2e test to make sure the usage is tested?

[ishitasequeira]

@crenshaw-dev , thanks for testing that out. I updated the doc to remove comma-separated and added example for manifests command.

Should we add an e2e test to make sure the usage is tested?

Unfortunately, the current setup for e2e tests, would not work for cli commands of multiple sources.

[crenshaw-dev]

LGTM!