Prevent new uses of old ztest API

[yperess]

Discussed in the TSC meeting, we need a way to prevent new uses of the ztest API.

I believe that the best way to do this will be to add a new check for PRs similar to a language filter that checks for inappropriate language. To do this we'd need:

1. Create a new repo something like zephyrproject-rtos/word-blocklist
2. Provide an implementation of the GitHub check that scans for new test suites:
   a. ztest_register_test_suite
   b. ztest_test_suite

I don't believe that we should block adding more tests to existing suites. That will automatically happen as people migrate to the V2 API.

Once we're done, zephyrproject-rtos/word-blocklist can remain and we can use this for other migrations. It's also possible that we can find an existing GitHub CI for profanity filter and simply fork it. I don't think it'll be a bad idea anyway to have a profanity filter.

[yperess]

@nashif

[yperess]

@aaronemassey

[teburd]

The docs likely need to be updated to use only newer methods as a first step for this. The docs at https://docs.zephyrproject.org/latest/develop/test/ztest.html still shows samples and such with what I guess should no longer be allowed.

[mbolivar-nordic]

Process WG:

• @mbolivar-nordic: how does a word blocklist allow you to say "the $BLOCKED_WORD API is now deprecated"?
• @MaureenHelm : not sure why we don't use the regular deprecation process -- is there something special about this?

@yperess can you attend next week to discuss further if there's still something to handle here?

[yperess]

Process WG:

• @mbolivar-nordic: how does a word blocklist allow you to say "the $BLOCKED_WORD API is now deprecated"?
• @MaureenHelm : not sure why we don't use the regular deprecation process -- is there something special about this?

This is for long migrations that take time. If we deprecate the old API our CI will break. We just want to prevent new uses.

@yperess can you attend next week to discuss further if there's still something to handle here?

Sure

[mbolivar-nordic]

Process WG: defer; @yperess couldn't make it.

@nashif next steps should be "complete, deprecate, remove;" I'd like to year @yperess 's points about this, though.

[yperess]

Sorry, I was stuck in another meeting. The idea of this workflow was to provide the following:

1. We have a new API that Zephyr itself is in the process of migrating to. We cannot mark the old API as deprecated or it'll break our own CI.
2. We use the blocklist CI tool to prevent new uses of the old API.
3. We complete the migration of the old API to the new one (because new uses of the old API are prevented by the blocklist we don't have to keep chasing)
4. We mark the old API deprecated

This issue was specific to the ztest API migration, and that's already got a lot of traction. I'm happy to just close this issue and ignore it, but I do think that this will come up again so it might be nice to have the mechanism in place.

[mbolivar-nordic]

OK, I'lll close this for now and we can see if we need to reopen in the future. Thanks.