It seems that when the same commit is tagged with both the testing and the stable channel, the stable channel's build will actually download the testing channels binary packages. This is not wrong per se. Yet, since the package is no longer actually build, it will not upload the package to the remote.
The solution could be to set the "CONAN_BUILD_POLICY" to the specific package name being build.
The current workaround would be to remove the build_policy setting from the build.py file and move it into the CONAN_BUILD_POLICY environment variable with the value all. This has the downside that all dependencies are build.
Another option could be to extend the version entry for the testing channel to include something like testing/0.0.1-pre0. With distinct names, we might have a chance to support uploading of the same recipe under two different names/channels.
Correction: When removing the current build_policy argument in build.py and letting it default to None, the process seemingly works as intended: Download and use dependencies but always build the current recipe.
Correction 2: This only works as long as there are prebuilt packages. If there is a pre-build package missing (for example for clang-10) then the build will fail.
Using all as the build policy works to solve this issue. Yet, I have uncovered gitlab-org/gitlab#210550 (comment 307476882) in my own testing. That means that conan_sources.tgz is not uploaded and therefore building the package from source on any machine that does not have the sources present in its cache will fail.
It seems that the conan integration in gitlab is not quite up for the task yet. Considering to move to the normal bincrafter/jfrog workflow.