Open alvarolopez opened 1 month ago
This limitation is only for Docker building, not for all tests. For example, user-defined tests run for any branch. And indeed, I don't see a reason to build Docker image for every branch.
1) federated-server and dev-env are indeed exceptional cases, but now they are in another organisation, github/ai4os and this "ai4os-hub-qa" does not apply for them
2) I don't see a reason to go away from the rather standard practices as "release/*", "main" etc. I am really getting in favor of following accepted practices as much as possible. We also had some considerations before, e.g.
Also to remind, if users are allowed to build "build/" or "deploy/", they are however, not allowed to remove these images. In other words, this may create a real mess.
I would close the issue without further action.
Is there a reason why we are not running qa for all branches?
Is it to save compute?
Because we need to think about how we are going to deal with the following usecases:
development environment: we are building tens of different tags (multiple Tensorflow versions, multiple Pytorch versions, etc) @vykozlov
demo app: we have branches
main
andreturn-files
which both need to be built.federated server: we have branches
main
andtokens
which both need to be built.I get that building images for every branch creates lots of noise. In fact demo app currently has multiples branches that I do not want to build.
Proposal: maybe have a
build/*
ordeploy/*
naming pattern (similar to the release one) that will trigger the qa?One could abuse the current
release/*
pattern, but I think it might be cleaner to have another one.What do you think?
Originally posted by @IgnacioHeredia in https://github.com/ai4os/ai4os-hub-qa/pull/8#pullrequestreview-2107069698