add warning logs for experimental & beta components

[jem-davies]

Bento components have an associated 'Status', that can take the value of "stable", "beta", "experimental" & "deprecated". Currently the only way a user of Bento would understand they were using a "beta" / "experimental" component is if they have seen the warning on the component's doc page.

This PR will add an additional type of Lint Warning such that when a "beta" or "experimental" component is parsed, we will emit a Warning log, users will be able to silence these warnings with additional options --allow-beta & --allow-experimental.

In a future major update to Bento, we could alter this behaviour so that Bento will not execute a stream with "experimental" or "beta" components, unless explicitly allowed by the user.

This PR will add warning logs when a stream is created via:

• bento 'normal mode' bento -c config.yaml
• bento components loaded via a resource file
• creation of streams via REST API
• bento 'streams mode' bento streams ./*.yaml
• watching config files
• bento lint ...

In a follow up PR I will alter the StreamBuilder API to allow modifying if we will log warnings for experimental / beta components.

[jem-davies]

Expecting the test github action to fail - but it would be fixed by: #508

[jem-davies]

@gregfurman - this is ready for review 🙏

[gregfurman]

Why the change here?

[jem-davies]

iirc - I added a new test - but that test would always fail because it would call os.Exit - now providing that the code returned isn't 0 we just let the go program terminate without calling os.Exit allowing the test to run

[gregfurman]

Can we rather do this against a local version of the environment? Unsure we should be testing against the global one.

[gregfurman]

How come we moved this out to its own function?

[jem-davies]

Just thought it would be more tidy then the mixed approach we have with the flags at the moment.

[gregfurman]

What do you think about making these opt-in instead of opt-out? Like, --disable-experimental and --disable-beta to trigger these warnings.

Given how many users are likely using experimental or beta components, I'm concerned this is going to give the wrong impression of our plugin stability 😅

[jem-davies]

I would have liked it such that we make it so you have to --allow-experimental to even run the stream with an experimental component. So instead of the warning we fatally terminate the program. That is rather heavy-handed though so went with the LintWarn approach. (Maybe we do that in a Major version update instead).

The way the component statuses work at the moment, i.e. experimental, beta & stable - other than the doc page warning text - we don't have much else in terms of protection. And to a user I suppose there is nothing else that differentiates them.

Because of that I feel we are reluctant to make breaking changes to experimental components. I feel that with these changes as-is - we might get more feedback from the community regarding if they are using an experimental component - and also we can be more assured to accept PRs with experimental components too.

I'm concerned this is going to give the wrong impression of our plugin stability

I agree - but I think that the fix to that is to do more 'promotion' of our existing components.

We can hold this PR off for now until we are happy with the current state of component statuses.

(Also would consider removing Beta entirely as a status).

Experimental - should be for new components - that might get changed further in the near future - and also might not have as many int. tests attached to them etc.

Stable - The majority of components should just be considered stable

[jem-davies]

What do you think about making these opt-in instead of opt-out? Like, --disable-experimental and --disable-beta to trigger these warnings.

Feel like that approach might just bury the --disable-experimental CLI flag in the CLI help page and just won't get used.

[gregfurman]

We could also just add a pre-run check that retrieves the ConfigView and checks if the component in question is stable or not. Would need to add a:

// IsStable returns true if the component is marked as stable.
func (c *ConfigView) IsStable() bool {
	return c.component.Status == docs.StatusStable
}

And then we can check:

isStable := GlobalEnvironment().GetProcessorConfig(name).IsStable() // or GetInputConfig etc.
if !isStable {
   return fmt.Errorf("cannot create a processor of type %s: component is marked as unstable")
} 

Perhaps similar to what we do with our bundle approach and walk all processors before creating the manager:

var err error
GlobalEnvironment().WalkProcessors(func(name string, config *service.ConfigView) {
   if !config.IsStable() {
         err = fmt.Errorf("cannot create a processor of type %s: component is marked as unstable", name)
   }
})

return err

[gregfurman]

What are your thoughts on adding a grouped warning log instead of 1 per component? Perhaps that will make this change less scary to use.

For example:

[Warning] the following components are unstable and subject to changes outside of major versions: [ ... ]

Thoughts?