Fixes EIMP lint errors as per the latest OTel version

[lahsivjar]

Fixes the lint failures as a result of update to v0.105.0. Most of the code is auto-generated other than the following changes:

1. The actual EIMP codebase (not the generated ones) change for CreateSettings -> Settings.
2. OCB version bump up for the testing distro.

I also noticed that lints are not run as part of the GH checks, this is what caused the lint error to go unnoticed. I will create a followup for this. This is not correct, not sure why the errors were not reported with the dependabot PR.

[ishleenk17]

@lahsivjar : If this processor is used with components on version lesser than v0.105.0.
Would it cause any compatibility issue?

[lahsivjar]

@ishleenk17 CreateSettings was deprecated in v0.103.0 and that's when the Settings was introduced. So, it would probably be incompatible with versions before v0.103.0.

I might be mistaken here but is this an issue for us? Don't we have full control over which version of the component we will package in our distro?

[lahsivjar]

BTW, if the CreateSettings -> Settings is concerning for any reason then it should be okay to keep the CreateSettings. The main cause of test failures are UnmarshalConfig in the generated tests.

[rogercoll]

LGTM

[rogercoll]

@ishleenk17

If this processor is used with components on version lesser than v0.105.0. Would it cause any compatibility issue?

I don't think so because the NewFactory method that is the one used in the distribution has no changes. We could also release patch version from v0.7.1.

I have just modified the sample manifest of this branch with versions lower than v0.105.0 for the other components and compilation works accordingly:

  otelcol_version: 0.105.0

extensions:

connectors:

converters:

receivers:
  - gomod: go.opentelemetry.io/collector/receiver/nopreceiver v0.101.0

processors:
  - gomod: github.com/elastic/opentelemetry-collector-components/processor/elasticinframetricsprocessor v0.0.0

exporters:
  - gomod: go.opentelemetry.io/collector/exporter/nopexporter v0.101.0

[lahsivjar]

@rogercoll

otelcol_version: 0.105.0

If you keep the otelcol_version as > v0.103.0 then you won't have failures but if you use anything below that it should fail I think (since before that version the Settings struct does not exist).

I will wait for this discussion to conclude before merging. Alternatively, we can merge #40 which would fix the test but not the lint.

[lahsivjar]

I might be mistaken here but is this an issue for us? Don't we have full control over which version of the component we will package in our distro?

Going back to this, why would we ever publish your distro with older version of the components? I thought we had full control over the versions we would ship with the distro - if this is true then I don't see any issues with maintaining backward compatibilities.

@ishleenk17 I saw that you approved the PR, does the above resolve the backward compatibility concern?

[ishleenk17]

I might be mistaken here but is this an issue for us? Don't we have full control over which version of the component we will package in our distro?

Going back to this, why would we ever publish your distro with older version of the components? I thought we had full control over the versions we would ship with the distro - if this is true then I don't see any issues with maintaining backward compatibilities.

@ishleenk17 I saw that you approved the PR, does the above resolve the backward compatibility concern?

Yes, considering that we will always have the latest otelcol version for our Distro, I have approved this.