LLM suggested fix so that CI pipelines don't run twice.

[BrendanKKrueger]

Closes #53

[BrendanKKrueger]

@cferenba and/or @spakin, could one of you take a look and double-check me on this?

[cferenba]

Not that I'm a CI expert, but it looks sensible to me.

[spakin]

I don't recall ever seeing the CI run with branches: '**'. I suspect that the LLM is referring to the fact that the branch will run CI and then main will run the CI again when merged. I do prefer that behavior, though, because if one person creates a branch, he'll know immediately if it fails CI. Otherwise, he'll have to wait until the branch hits main.

[cferenba]

I think this is referring to the previous CI runs on both "pull-request" and "push", which I believe refer to "run your branch as-is" and "run your branch merged into main" respectively. Both run simultaneously when CI runs. I think the current change will mean that only the latter will run, which seems reasonable to me.

[BrendanKKrueger]

I think this is referring to the previous CI runs on both "pull-request" and "push", which I believe refer to "run your branch as-is" and "run your branch merged into main" respectively. Both run simultaneously when CI runs. I think the current change will mean that only the latter will run, which seems reasonable to me.

It's entirely possible that I've misunderstood things, but Charles is right that this is trying to address the fact that I get a "push" pipeline and a "pull_request" pipeline for every push to every merge request. If they're different, then I didn't understand that. But it just looked like it was always running the CI pipeline twice and that was a waste of compute resources and meant I had to wait extra time for both pipelines to finish.

[spakin]

All right. Let's assume that I'm mistaken and that merging this pull request really will prevent CI from running more than it needs to.

[BrendanKKrueger]

All right. Let's assume that I'm mistaken and that merging this pull request really will prevent CI from running more than it needs to.

I asked Claude and was told that "push" runs the state of the source branch and "pull_request" runs the state of the post-merge target branch. So Scott is right that there's a meaningful difference. I'm used to workflows that force merge requests to be up-to-date so that they would effectively be the same, but it appears that's not required the way this repository is currently configured (and I've not played with the settings to see if I can change that).

Option 1: leave things alone

• A merge request does NOT need to be up-to-date with the target branch before merging
• You get a test of the result of merging into the destination branch
• You get a test of the current state of the source branch

Option 2: merge this PR as-is

• A merge request does NOT need to be up-to-date with the target branch before merging
• You get a test of the result of merging into the destination branch
• You do NOT get a test of the current state of the source branch

Option 3: play with the settings, merge this PR as-is

• A merge request MUST be up-to-date with the target branch before merging
• You get a test of the result of merging into the destination branch
• You do NOT get a test of the current state of the source branch, but that should be identical to the post-merge destination branch

Thoughts on doing Option 3? Will that satisfy all our goals? Or should we just go with Option 1?

[spakin]

I'm not sure we want to force the merge request to be up-to-date with the target branch. Not that QHAT is super-active, but I envision getting stuck in a loop of "I submit a pull request—someone else updates main—the merge fails—I rebase and force-push—someone else updates main—the merge fails—I rebase and force-push—someone else updates main—etc."