From Serg on slack:

I have two ideas how to do it.
• a separate branch, like bb-10.2-cc-merge. Every C/C push will update C/C in this branch and push (or force-push, whatever). This will naturally trigger buildbot
• modified tarbake rule, on C/C push it'll build a tarball with the latest C/C. Other builders won't care, they just use a tarball. But it's important that at least some Windows builders will build it, not sure if they use tarballs.

Thinking about it, it seems natural to implement the git-branch-based solution above by using the same mechanism that ratzpo is working on in the scope of MDEV-12511 (staging and fire-and-forget). In this case the C/C branch would represent the "staging" branch, and if it builds/runs okay, buildbot would push or force-push into the "merge" branch. ratzpo, serg, is it possible to re-use the same approach?

If you think it will take too long and can't happen within the next month (by the next 10.2 release which is planned for December 21st), I can of course still implement the second buildbot-config-based solution as a temporary workaround. It should be technically not very difficult, although it will require a lot of duplication in the buildbot config, and also it will trigger unnecessary dirty builds on the server tree when/if the connector itself is broken and either doesn't build or doesn't run properly.

fire-and-forget question is for ratzpo.

As far as buildbot-approach goes, I don't think it'll be much of the duplication. One only needs to allow tarbake to be triggered by the "3.0" branch (better make it a variable, similar to DEVELOPMENT_BRANCH). And inside the tarbake build script: if branch is 3.0, pull 10.2 server and use 3.0 commit as specified, configure and build normally.

ratzpo wanted it to be assigned to him, so I'm re-assigning.

For the time being I have set up the tests in buildbot (temporarily, until the solution from ratzpo is in place). Indeed, it did not require any duplication, because tarbake did not do anything meaningful for connectors branches (I thought it did, and we would have to have two tarbakes). In fact, tarbake was just starting for connectors trees, fetching sources and failing as soon as it tried to build the source package. Now I've made it to do what's required in the scope of this task for 3.0 branch, and bail out on other connector-c branches without attempting a build.

The basic logic is this:

if [[ "$REMOTE" == "MariaDB-mariadb-connector-c" ]] && [[ "%(branch)s" == "3.0" ]]; then

  echo "MDEV-17688 - buildbot to test latest C/C 3.0 branch with the latest server 10.2 branch"

  git remote add MariaDB-server https://github.com/MariaDB/server || true

  git fetch --prune MariaDB-server

  git checkout --force MariaDB-server/%(server_branch_for_connector_c)s

  rm -rf libmariadb

  git clone $URL --branch "%(branch)s" libmariadb

else

  <as it was>

There are also some changes which make 3.x a logical equivalent of 10.2+, as we rely on the branch name to define the test behavior in several places.

I haven't made the connector branch a variable like DEVELOPMENT_BRANCH, because I thought we might want to run these tests for more than one branch at once, e.g. 3.0 and 3.1. We can, however, make it a list-like if needed.

Note: Maybe even better solution would be not to trigger tarbake for connector-c branches unless they fall in the area of our interest, but it requires a little more than doStepIf, because if we do so, the tarbake compilation is _skipped, the whole tarbake test passes, and it triggers a bogus test run with whatever previous tarbake the slave had._

Anyway, since it's supposed to be a temporary solution, I didn't try to bring it to a long-term perfection.

Here is a test run on 3.0 (forced):
http://buildbot.askmonty.org/buildbot/grid?category=main&branch=3.0
It actually uses bb-10.2-release rather than 10.2, because at the moment 10.2 is broken, but I changed the config back to 10.2 after this run.
I also checked that the tarbake is properly triggered by a regular push. It also triggers (as it does for any connector pushes) some unwanted builds, e.g. Windows debug, which fails in the matter of seconds, but this is an old nuisance out of the scope of this task.

Most recent occurrence: main.tls_version was broken in 10.4 because of a libmariadb change that appeared to work in 10.2 and 10.3. 10.4 is different, because it is the first branch to use WolfSSL for cmake -DWITH_SSL=bundled. And again, Windows caught the bug, because other platforms use -DWITH_SSL=system.

Temporary workaround: In the merge to 10.4, I used an older libmariadb commit.

it doesn't make sense to spend buildbot resources on running tests that nobody looks at.
Branch protection for C/C (travis, azure, anything) would work better.