Any way to filter automatic GitHub Build events?

[Francisco Cano Brusa]

Hi!

We have a repository that builds and deploys using CircleCI, but due to an ongoing migration to GitHub actions in the company, we have started implementing some workflows to validate certain fields in the PR and run certain checks.

The Compass UI is considering _any_ GH workflow as a "build". For example, we have an action called "jira-validate" that uses the "atlassian/gajira-find-issue-key" action and validates that a PR has a valid Jira ticket. Even _that_ action is counting as a build. That is artificially reducing our build time...

I'm expecting to be able to configure the CircleCI integration some time in the future, but even still, not being able to filter the GH workflows that do the build from others seems like it can be a problem in other repositories....

Is there a way to change how this automatic "build" detection is made?

[Josh Campbell]

Hey Francisco, Josh here from the Compass product team! It really comes down to how GitHub actions works, everything is a "job" within a GitHub actions workflow so there is not a good way to discern which jobs are just builds with no deployments that we can ignore for the purposes of metrics. And as long as an "environment" key is passed in the job parameters we'll detect that because that is the only way to know if a GitHub actions based deployment happened (there is no "deployment" key like in Bitbucket so we know a specific job was definitely a deployment).

I've thought a bit about this before and poked at the GitHub docs to see if there is a solution that could work for all/most customers, but outside of forcing a specific naming convention of job names to perhaps filter non-deployment jobs I am not sure there is an easy win here. If you have suggestions as someone probably more familiar with GitHub actions than me I am absolutely open to hearing them!

Perhaps the right approach could be some UI work we could do to help you define filters/regex for jobs - that's a non-trivial effort but it might the right path. Keen to hear any other thoughts!

[Francisco Cano Brusa]

Thanks for the reply Josh!

I understand this is not trivial to solve. I was thinking that what could work for us (and could be simpler than a regex), is to simply disable autodiscovery on a per-service basis.

Then to those services without autodiscovery enabled, we'll be in charge of manually sending the cURL requests to tell Compass when something is being built.

The option you mention seems better, but something simpler would suit us just fine at the moment ;)

Hope the feedback is useful, have a good day!

[Gabriele Nosso]

The way that DevLake works is indeed with RegEx.
Would be great to have this feature, as it would also allow to gather historical data - which is something impossible at the moment if you are not using the "environment" parameter.

[Greg Bernstein]

What if we could just disable build events from certain repos? We have an auto-approve action on a given repo but do all of our builds on a different service, so none of the actions in that repo represent deployments. It also doesn't access any environment variables, but might be getting caught up because it accesses the GITHUB_TOKEN secret?

A more flexible way might be if you could blocklist certain action names on the jira side, maybe in the project configuration?