Use stdlib function instead of own to check for slice membership

[ycombinator]

Quick cleanup on the heels of #9266. Thought of this right after I merged that PR 🤦.

[elasticmachine]

Pinging @elastic/elastic-agent-control-plane (Team:Elastic-Agent-Control-Plane)

[elasticmachine]

💛 Build succeeded, but was flaky

• Buildkite Build
• Commit: 910c382

Failed CI Steps

• x86_64:non-sudo: default

cc @ycombinator

[pkoutsovasilis]

Tbh I reviewed the original PR and I thought that you went the manual approach becuase slices.Contains does essentially the following

package slices
 
// Contains reports whether v is present in s.
func Contains[S ~[]E, E comparable](s S, v E) bool {
	return Index(s, v) >= 0
}

// Index returns the index of the first occurrence of v in s,
// or -1 if not present.
func Index[S ~[]E, E comparable](s S, v E) int {
	for i := range s {
		if v == s[i] {
			return i
		}
	}
	return -1
}

and because you pass pointers this essentially is not checking the version equality but the ptr ref, what am I missing?

Also I see in the CI that adding the label doesn't invoke the step which is really weird

[ycombinator]

and because you pass pointers this essentially is not checking the version equality but the ptr ref, what am I missing?

Yeah, good point. I could do something like this:

for _, ver := range versions {
	if slices.ContainsFunc(echVersions, func(candidateVer *version.ParsedSemVer) bool {
		return candidateVer.Equal(*ver)
	}) {
		filteredVersions = append(filteredVersions, ver)
	}
}

But I'm not sure that's buying us much over the current manual approach. WDYT?

Also I see in the CI that adding the label doesn't invoke the step which is really weird

In fairness, I added the label after the CI run had already started. Let me rebuild now and see if the label takes effect.

[elastic-sonarqube]

Quality Gate passed

Issues
0 New issues
0 Fixed issues
0 Accepted issues

Measures
0 Security Hotspots
No data about Coverage
0.0% Duplication on New Code

See analysis details on SonarQube

[pkoutsovasilis]

Yeah, good point. I could do something like this:

for _, ver := range versions {
	if slices.ContainsFunc(echVersions, func(candidateVer *version.ParsedSemVer) bool {
		return candidateVer.Equal(*ver)
	}) {
		filteredVersions = append(filteredVersions, ver)
	}
}

But I'm not sure that's buying us much over the current manual approach. WDYT?

It feels like the same approach that is already there 🙂

Also I see in the CI that adding the label doesn't invoke the step which is really weird

In fairness, I added the label after the CI run had already started. Let me rebuild now and see if the label takes effect.

I cannot wrap my head around how BK reacts to the gh labels, because the test is still not invoked

[ycombinator]

It feels like the same approach that is already there 🙂

Agreed. Let's just stick with what we already have. Closing this PR unmerged.

I cannot wrap my head around how BK reacts to the gh labels, because the test is still not invoked

Same. Let's use #9286 to fix the automation for this label.