github-actions: use them instead of buildkite

[v1v]

What

• Use GitHub actions
• Remove Buildkite support
• Fix license year
• Add dependabot for GH actions

Why

• github-action: add catalog-validate for GitHub actions #24 (comment) pointed about some issues with the VM images and the Golang ecosystem.
• Run faster builds.
• Reduce environmental issues.
• Simplify the maintenance by using the self-hosted GitHub runners.

Build times

From 9 minutes, see here, to 1min and 20 seconds, see here

vs

[v1v]

I've just found that ubuntu-latest or windows-latest will have some issues with perl:

=== RUN   TestParseWithPatterns_Rails/RAILS3
    rails_test.go:120: 
        	Error Trace:	/home/runner/work/go-grok/go-grok/patterns_test/rails_test.go:120
        	Error:      	Received unexpected error:
        	            	error parsing regexp: invalid or unsupported Perl syntax: `(?<`
        	Test:       	TestParseWithPatterns_Rails/RAILS3

See https://github.com/elastic/go-grok/actions/runs/14880134219/job/41786078100?pr=25#step:5:959 or https://github.com/elastic/go-grok/actions/runs/14880134219/job/41786078561?pr=25#step:5:962

As far as I see windows-2022 uses Perl 5.32.1 vers windows-latest that uses Perl 5.40.0. Linux-latest uses Perl 5.38.2 versus Linux-22.04 that uses Perl 5.34.0.

[pkoutsovasilis]

ok why we still have a buildkite step that is red here?! 😄 also are you sure that you want to complete move away for BK? AFAIK this is the first repo that does it, not saying no just making sure that this is supported and won't run into any future issues

[v1v]

ok why we still have a buildkite step that is red here?!

I bet, because the catalog-info has not been deleted in main.

😄 also are you sure that you want to complete move away for BK?

Yes. I found it pretty simple to use GH actions for projects that don't need anything from the Elastic CI ecosystem or contribute to the Unified Release process.

In addition, it's free, faster, accessible and open, so contributors can see the CI logs.

AFAIK this is the first repo that does it, not saying no just making sure that this is supported

We have a large number of GH repositories using GH actions:

• https://github.com/elastic/apm-server
• https://github.com/elastic/apm-agent-java
• https://github.com/elastic/elastic-otel-java

To name a few. Even some of those projects need to use BK, they only use it when needed, nothing else. And the majority of the contributors are eager to change those GH actions as needed.

and won't run into any future issues

For golang projects, I think this works quite well. I cannot say why we should not use it.

BTW, I've detected some future issues regarding the perl version, see #25 (comment). I'd assume that's the same for the BK Build runners.