For the onboarding training, the "hello-preprocessor" is referenced and used as a way to introduce preprocessors (and other IMAGE microservices). It serves no other purpose except to be a simple preprocessor whose outputs can easily be changed. Other preprocessors, however, make external API calls, depend on prior preprocessors, or use machine learning models, and as a result are poor candidates to replace the hello-preprocessor.
This PR moves it back to its old place so that the instructions in the wiki can be followed.
Required Information
[ ] I referenced the issue addressed in this PR.
[x] I described the changes made and how these address the issue.
[ ] I described how I tested these changes.
Coding/Commit Requirements
[x] I followed applicable coding standards where appropriate (e.g., PEP8)
[x] I have not committed any models or other large files.
New Component Checklist (mandatory for new microservices)
[ ] I added an entry to docker-compose.yml and build.yml.
[ ] I created A CI workflow under .github/workflows.
[ ] I have created a README.md file that describes what the component does and what it depends on (other microservices, ML models, etc.).
For the onboarding training, the "hello-preprocessor" is referenced and used as a way to introduce preprocessors (and other IMAGE microservices). It serves no other purpose except to be a simple preprocessor whose outputs can easily be changed. Other preprocessors, however, make external API calls, depend on prior preprocessors, or use machine learning models, and as a result are poor candidates to replace the hello-preprocessor.
This PR moves it back to its old place so that the instructions in the wiki can be followed.
Required Information
Coding/Commit Requirements
New Component Checklist (mandatory for new microservices)
docker-compose.yml
andbuild.yml
..github/workflows
.README.md
file that describes what the component does and what it depends on (other microservices, ML models, etc.).OR