Are you also specifying a category for the analysis from those workflows, with the same category for each workflow? If a category is not specified, the CodeQL Action will generate a category for you, which by default includes the workflow name. This means the alerts from the two separate workflows would be considered distinct and wouldn't be correctly matched against each other.

For this reason, we generally recommend having the same workflow with both pull_request and push triggers, and the warning is intended to prevent such a mismatch. However I appreciate your configuration is slightly more advanced -- could you please share with us a rough outline of your workflows, or the motivation for having separate pull request and push workflows? With that information, we can think more about how to support this use case, either by allowing you to suppress the warning or by some other more intuitive method.

Yes, I'm setting the category to the same value in both. Would it maybe make sense to suppress the warning if category is set?

The shared workflows here are intended for k8s deployed services. We use Skaffold, and typically Jib, to build images and render manifests.

Both workflows builds an image, runs unit tests and renders manifests. The PR workflow will additionally publish test reports and optionally diff the rendered manifests with the currently deployed ones and display the result. The push (main) workflow will start a deployment flow by pushing the rendered manifests to a "deployment" branch and then start a job that is waiting for a Argo CD to report back the result via a GH check.

It's obviously possible to put all of this in a single workflow but that would end up being a bunch of if-else spagetti. We could also keep the CodeQL stuff in a separate workflow that only does that, but that means there is more boilerplate needed in each repo, which is something we're trying to avoid with the shared workflows.

@adityasharad Any more thoughts on this?

Thanks for explaining your use case, and for your patience while I discussed this with my colleagues. Your solution sounds sensible for that purpose.

A missing push trigger is unfortunately quite a common mistake from regular usage, and it's challenging to know from a single workflow whether the analysis has been configured correctly across multiple workflows, even if categories are in use. So we'd like to be careful about giving all users the option to suppress the warning, until we encounter more use cases similar to your own. Should we see more demand, we'll revisit your (sensible) suggestion of adding a suppression option.

However, I appreciate your desire to avoid the warning confusing the devs using your shared workflows. Here is a workaround that we think will help you avoid the warning, without meaningfully impacting your devs or changing the behaviour of your workflows. Will this work for you?

• In the PR workflow, add a push event trigger:

   on:
     pull_request:
       # same as before
     push:
       branches: [main]

• In the PR workflow, add an if condition on every job so that it doesn't actually run on the push events:

  jobs:
    job1:
      name: ...
      if: github.event_name == 'pull_request'
      # rest as before

• You will now see additional runs of the PR workflow in the Actions runs UI, corresponding to push events to main, but all jobs in those runs will be skipped, and no compute will be used for those jobs. This should not affect the status of any PRs.

Thanks for the suggested workaround but the problem with it is that it needs to be added in every caller workflow which is something we'd like to avoid. Having this unexpected trigger/if condition everywhere and seeing the skipped jobs would potentially be even more confusing for all devs using the shared workflow than seeing the warning.

I'd kindly ask you to reconsider providing an explicit option to suppress the warning - as opposed to my suggestion about always suppressing it when category is provided this can't really be done by mistake. I would also be willing to create a PR if you were to reconsider.