Closed Trolldemorted closed 1 year ago
With the current structure of enochecker_test, that would not be possible since we are only using the HTTP-API of the checker and don't have access to the file system
with all due respect, I am fairly certain that virtually all deployments of enochecker_test do have the checker installed on the same file system 😇
Since COMPOSE_PROJECT_NAME
is an env var, we could expose it through an HTTP interface - or would that be overengineering? The benefit would be being able to test whether the checker info request service name matches the environment variable.
I think something like a dedicated GitHub Action would be more appropriate here, since we would not have to make any assumptions about the layout of the directory structure then.
I think exposing the COMPOSE_PROJECT_NAME
would indeed be overengineering.
Also, we would still need to define a "blacklist" of COMPOSE_PROJECT_NAME
-values. Currently a lot of people simply copied the example which sets the variable to n0t3b00k_service
or something like this - so while everybody is setting that variable, there would still be collisions since people use the same name.
Can we do that @ldruschk ? Certain services and checkers still have no .env file that would set a
COMPOSE_PROJECT_NAME