feat: Matrix generator where a generator can reference items of another one#9080
Conversation
…ld generators reading parameters. Specifically, 2nd generator reading the 1st generator's parameters. Signed-off-by: jkulkarn <jay.p.kulkarni@blackrock.com>
Signed-off-by: jkulkarn <jay.p.kulkarni@blackrock.com>
Signed-off-by: jkulkarn <jay.p.kulkarni@blackrock.com>
355eaad to
5c7ae5a
Compare
Codecov Report
@@ Coverage Diff @@
## master #9080 +/- ##
=======================================
Coverage 45.82% 45.83%
=======================================
Files 222 222
Lines 26376 26405 +29
=======================================
+ Hits 12087 12102 +15
- Misses 12642 12652 +10
- Partials 1647 1651 +4
Continue to review full report at Codecov.
|
Signed-off-by: jkulkarn <jay.p.kulkarni@blackrock.com>
|
it looks good to me, plz include test case, also it would be great to have the usage documented with example as only second generator refers params of 1st |
Signed-off-by: jkulkarn <jay.p.kulkarni@blackrock.com>
Signed-off-by: jkulkarn <jay.p.kulkarni@blackrock.com>
Signed-off-by: jkulkarn <jay.p.kulkarni@blackrock.com>
|
@rishabh625 - Awesome sounds great!. Writing up the tests right now. Looking through the ArgoCD Repo as to where I can update edit the Matrix generator docs, but I don't see them under "applicationset" directory, and the regular docs don't seem to mention them. So my question is:
Thanks, and let me know! |
|
I guess you need to update docs here, as docs is moved #8955 Are we going to change hosting of application set docs |
|
@KojoRising docs are now kept in docs/operator-manual/applicationset in the argo-cd repo |
…strictions regarding child generator B consuming parameters produced by child generator A/ Signed-off-by: jkulkarn <jay.p.kulkarni@blackrock.com>
|
Thanks @crenshaw-dev, found it! I've updated the Matrix Generator documentation to include the following:
I added the restrictions to the bottom (where the other Matrix Generator Restrictions are), but let me know if I should explicitly make those restrictions clear in the section with the example. Thanks! |
Signed-off-by: jkulkarn <jay.p.kulkarni@blackrock.com>
| tmpParams := make(map[string]string) | ||
| for _, currParam := range params { | ||
| for k, v := range currParam { | ||
| tmpParams[k] = v | ||
| } | ||
| } |
There was a problem hiding this comment.
After this block of code, won’t tmpParams contain whatever was in the last map in the params list for a given key? Meaning that the templating below would always interpolate the last value for a given key instead of each value for a given key?
If I’m understanding the use case, it seems params should be a map (instead of a list of maps) and then the matrix generator code would look something like:
g0, err := m.getParams(appSetGenerator.Matrix.Generators[0], appSet, map[string]string{})
for _, a := range g0 {
g1, err := m.getParams(appSetGenerator.Matrix.Generators[1], appSet, a)
for _, b := range g1 {
val, err := utils.CombineStringMaps(a, b)
if err != nil {
return nil, err
}
res = append(res, val)
}
}…where g1 is determined for each param map a from g0.
There was a problem hiding this comment.
So, hmm, so I think basically each "previous" generator's params are stored in each array index. So you are right in that it will only take all of the last generator's params.
But because the Matrix Generator only can have 2 child generators, I think it'll always be an array of size 1. So taking the last index shouldn't be an issue (although know you mentioned it, I think I can possibly replace the entire thing w/ just params[0] instead of tmpParams
So this is how the "params" function parameter value looks like

Signed-off-by: jkulkarn <jay.p.kulkarni@blackrock.com>
| } | ||
| argoCDServiceMock := argoCDServiceMock{mock: &mock.Mock{}} | ||
|
|
||
| argoCDServiceMock.mock.On("GetDirectories", mock.Anything, mock.Anything, mock.Anything).Return(cases[0].repoApps, cases[0].repoError) |
There was a problem hiding this comment.
You define several cases but only appear to use the first one.
There was a problem hiding this comment.
Ahh yeah, this was more for testing the GetRelevantGenerators function (not mine). I'm fairly new to Go (I'm more on the ArgoCD Yaml side :), so I was using some tests that were used for the Git Generators (where they were specifically testing the Git Generator).
My test cases were below in the TestGetRelevantGenerators function:
Anyways, I cleaned up the above function you mentioned. Thanks for pointing it out!
applicationset/generators/matrix.go
Outdated
| return nil, err | ||
| } | ||
| g1, err := m.getParams(appSetGenerator.Matrix.Generators[1], appSet) | ||
| g1, err := m.getParams(appSetGenerator.Matrix.Generators[1], appSet, g0) |
There was a problem hiding this comment.
Regarding your “I think it'll always be an array of size 1” comment from the other thread, isn’t g0 all items from the first generator? And doesn’t it eventually become the params parameter to your new interpolateGenerator function? I’m unclear how the new example you added to Generators-Matrix.md can be satisfied unless g1 is evaluated for each item in g0, instead of only for the last item in g0 (which we seem to agree is what’s happening based on that loop in interpolateGenerator).
I suggest additional test case(s) in matrix_test.go to validate the complete results from a matrix generator using this functionality (specifically where the first generator yields multiple items).
I’m very interested in this PR for some of my own use cases and I’d try to help out but so far, I’ve been unsuccessful getting a local environment up and running.
There was a problem hiding this comment.
Hi @Lobstrosity,
So as to the example you were referring to, I'm not sure if you were able to check my TestInterpolateGenerator function. I had the following example which was very similar to the example I had in Generators-Matrix.md (actually it used more parameters than the example). As you can see in the below test case, the cluster-generator is using 3 different parameters that should be created by the git generator.
If g1 does need to be evaluated for every item in g0, (by item, I'm assuming we're both referring to parameter generated for that particular generator), and that it currently only evaluates the last item, then wouldn't you agree that:
- All the keys for this label-selector's values - Be evaluated with the last item in the params list (ie.
app3) - All these test-cases be failing?
There was a problem hiding this comment.
Also though, I will try your above code snippet and see if I can observe a difference.
g0, err := m.getParams(appSetGenerator.Matrix.Generators[0], appSet, map[string]string{})
for _, a := range g0 {
g1, err := m.getParams(appSetGenerator.Matrix.Generators[1], appSet, a)
for _, b := range g1 {
val, err := utils.CombineStringMaps(a, b)
if err != nil {
return nil, err
}
res = append(res, val)
}
}There was a problem hiding this comment.
Also @KojoRising m unsure the example in Generators-Matrix.md is workable with this code. i would be good to see a e2e test.
…upport' into feat/add-intra-generator-param-support
| gitGeneratorParams := []map[string]string{ | ||
| {"path": "p1/p2/app3", "path.basename": "app3", "path[0]": "p1", "path[1]": "p2", "path.basenameNormalized": "app3"}, | ||
| } |
There was a problem hiding this comment.
@KojoRising Regarding this comment and the screenshot with the arrows:
This gitGeneratorParams mock represents a git generator that yields a single result. My concern is, what happens when the git generator yields multiple results? All of those results would be in g0 over in matrix.go but interpolateGenerator is only interpolating values from the first result.
There was a problem hiding this comment.
Ahh, got it got it. Yes, you’re right, for multiple paths specified in a git generator, it wouldnt pick those up.
I’ll update the code/test-cases to support this. Thank you for pointing it out!
Signed-off-by: jkulkarn <jay.p.kulkarni@blackrock.com>
|
@Lobstrosity, @rishabh625, @crenshaw-dev Need some input from your folks here. This issue is in line with what Lobstrosity pointed out above. So roughly
And even if I manage to save a copy of the string, the following is obviously going to be invalid YAML: ========================================================================================== So my question for y'all is do you think the below: I can't really think of another way of representing it?. Unless I create two appsets, or two matrix generators with that interpolation resolved. |
Signed-off-by: jkulkarn <jay.p.kulkarni@blackrock.com>
0bab357 to
50c70b1
Compare
|
@KojoRising fixing the DCO check is a pain. Looks like just this one commit message needs to be fixed:
|
|
Thanks @crenshaw-dev - I was about to ask you for some advice there. I'll try fixing that commit message rn. I was trying these steps from the DCO docs:
|
|
@crenshaw-dev any advice here? I was trying to find some resources to help, but I think it just created new commits w/ the changed Author, rather than fixing that commit (I still see DCO identifying that particular commit as an issue). |
|
I think it's gonna be tedious... basically If you wanna hop on a call, feel free to find me on CNCF Slack! :-) |
62e0ff5 to
4a665ac
Compare
Changed all numbering back to 1 in "Restrictions" section Signed-off-by: Jay P Kulkarni <jkulkarni@ucla.edu>
1) Removing part of comment in generator_spec_processor.go that was for an earlier iteration of code 2) Returning nil instead of an empty map in matrix.go 3) Creating a full-test (TestInterpolatedMatrixGenerate) in matrix.go. This example is not exactly the same, but very similar, to the example appset I had written in the Matrix Docs (also part of this PR). Signed-off-by: jkulkarn <jay.p.kulkarni@blackrock.com>
4a665ac to
c4c4654
Compare
|
@crenshaw-dev - Can you take a look :))? Think it's good to go now. Thanks again!! |
crenshaw-dev
left a comment
There was a problem hiding this comment.
LGTM! Thanks so much all, especially @KojoRising!
|
Haha, thanks so much @crenshaw-dev!! Appreciate all the reviewing, it's been a long, but fun PR. Thanks again @Lobstrosity, @rishabh625, @jannis-a, @rumstead for helping me get through this!!! |
@KojoRising @rumstead amazing stuff gents! |
|
Thanks everyone for the work. In which version of ArgoCD will this available? 2.4.1? |
|
@gaeljw since it's a new feature rather than a bugfix, I plan to let it wait until 2.5.0, which should be released in August. |
|
Sure, good to know @crenshaw-dev 👌 |
|
Sorry for a dumb question folks, is there a dev image pushed somewhere with this feature inside? @KojoRising @crenshaw-dev |
|
applying above manifests won't work @olegeech-me , but I think , applying manifests from this repo master branch should work |
|
Also @olegeech-me if you wanna try via kustomize (that's how I currently do it): You can just pin it to the latest commit and do a apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
namespace: argocd
resources:
- https://github.com/argoproj/argo-cd/manifests/ha/cluster-install?ref=2b5371681f611ca05c1884000bd236a38e02f167Or non-pinned latest apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
namespace: argocd
resources:
- https://github.com/argoproj/argo-cd/manifests/ha/cluster-install |
|
thanks a lot! appreciated. |
|
Is this going to work for merge generators too ? |
|
@jeromepin I believe this work was limited to only matrix generators, but I could be remembering wrong. |












Link - argoproj/applicationset#530
Fixes [ISSUE #530]
Note on DCO:
If the DCO action in the integration test fails, one or more of your commits are not signed off. Please click on the Details link next to the DCO action for instructions on how to resolve this.
Checklist: