The build.sh script is mostly unnecessary and does not provide any benefits over handing the building from the operator-sdk's binary. In addition, any updates that the sdk gets will not be reflected in existing project as build.sh is generated on new. Currently, this will cause issues for people created a project before the --enable-tests flag was added to the sdk and then try to use --enable-tests.
In addition, we should look into the way that dockerfiles are managed in cases like this. Currently, the above situation (trying to build an image with tests on a project that was generated before that was supported) will not work even with the build script merge because it will be missing the test-framework dockerfile. For now, we can just check if it exists and generate it if it doesn't, but in the long-term, we should find a better solution for managing these files.
The build.sh script is mostly unnecessary and does not provide any benefits over handing the building from the operator-sdk's binary. In addition, any updates that the sdk gets will not be reflected in existing project as
build.shis generated onnew. Currently, this will cause issues for people created a project before the--enable-testsflag was added to the sdk and then try to use--enable-tests.In addition, we should look into the way that dockerfiles are managed in cases like this. Currently, the above situation (trying to build an image with tests on a project that was generated before that was supported) will not work even with the build script merge because it will be missing the test-framework dockerfile. For now, we can just check if it exists and generate it if it doesn't, but in the long-term, we should find a better solution for managing these files.