Migrate from CircleCI to GitHub Actions

[bryce-souers]

This is in response to Issue #1341 "Move from Circle CI to Github Actions".

I took heavy inspiration from the Prometheus implementation here:
https://github.com/prometheus/prometheus/blob/main/.github/workflows/ci.yml

Implementation notes

New secrets are required

You must add the following secrets to be used in the ci.yml GitHub Action:
https://github.com/prometheus/blackbox_exporter/settings/secrets/actions

DOCKER_HUB_LOGIN
DOCKER_HUB_PASSWORD
QUAY_IO_LOGIN
QUAY_IO_PASSWORD
PROMBOT_GITHUB_TOKEN

For my testing, I had to create my own secrets in my forked repository.

Removing skipped tests

In this pull request, I removed all skipped tests that were skipped due to "CI" and validated that they work fine.

Adding skip to TestChooseProtocol

As was called out in #1341, IPv6-related issues were ran into but they appeared to only fail TestChooseProtocol for Windows.
I have adjusted the test to be skipped accordingly under those conditions.
I feel this is fine as we are testing on 2 other OS's.

Testing

In order to test this, I forked the repository and made many commits to my master branch (as that's the branch that I had to apply Actions configurations to for GitHub to pick them up).

Here are the results, laid out by what condition was tested and what the outcome was:

Condition

Create new branch and publish to remote with changes.

Outcome

1 Github Action was triggered and it ran the Test job.

---

Condition

Create pull request of new branch to master.

Outcome

1 Github Action was triggered and it ran the Test and Build common architectures jobs.

---

Condition

Push change / merge pull request into master.

Outcome

1 GitHub Action was triggered and it ran the Test, Build all architectures, and Publish master jobs.
DockerHub’s master tag was updated.
Quay’s master tag was updated.

---

Condition

A release PR is created and merged into master.
A tag for v0.30.0 is created:

~/workspace/repos/blackbox_exporter migrate_github_actions ❯ git tag -a v0.30.0 -m "v0.30.0"
~/workspace/repos/blackbox_exporter test_release_0.30.0 ❯ git push origin tag v0.30.0    
Enumerating objects: 1, done.
Counting objects: 100% (1/1), done.
Writing objects: 100% (1/1), 161 bytes | 161.00 KiB/s, done.
Total 1 (delta 0), reused 0 (delta 0), pack-reused 0
To https://github.com/Bryce-Souers/blackbox_exporter.git
 * [new tag]         v0.30.0 -> v0.30.0

Outcome

1 GitHub Action was triggered, and it ran the Test, Build all architectures, and Publish release jobs.
A release for v0.30.0 was created.
DockerHub’s master tag was updated.
Quay’s master tag was updated.

[electron0zero]

this will break when we go to 1.x.x release

[bryce-souers]

@electron0zero
Is it enough to add an OR where we also check if the tag starts with "v1." too?

Unfortunately, regex is not a part of the functions in GitHub Actions so we are stuck with checking the start, which is why I assume that Prometheus also does this using this method:

https://github.com/prometheus/prometheus/blob/02501e097e3ed31cb34ec7a42963d41718c90010/.github/workflows/ci.yml#L224C7-L226C79

It seems like it would be very hacky to try to work around this limitation of Actions to avoid a problem that is very easy to solve (just adding the relevant version prefix).

[electron0zero]

same here, this will also break with v1.x.x release

[bryce-souers]

See previous response.

[electron0zero]

if possible, we would like to avoid using third party actions, and would prefer to only use actions from actions and prometheus orgs.

[bryce-souers]

I do not see any actions from actions or prometheus that would allow this.

Prometheus kindly asks and hopes that people remember to update the .promu.yml to match the Go version:

https://github.com/prometheus/prometheus/blob/02501e097e3ed31cb34ec7a42963d41718c90010/.github/workflows/ci.yml#L12C7-L14C57

This seems more flimsy to me than directly pointing to a specific commit of a third-party that can just pull the go version from the .promu.yml file for us.

If you disagree, I can add a comment similar to Prometheus and hardcode the Go version, just thought this was better in my opinion.

[electron0zero]

I would like do this the way Prometheus does for consistency across repos in Prometheus org, we already have a similar comment for circleci.

blackbox_exporter/.promu.yml

Line 2 in 7d61fee

# Whenever the Go version is updated here, .circle/config.yml should also be updated.

[electron0zero]

any reasons to split the build into build_common and build steps?

[bryce-souers]

The idea was to build "common" architectures when someone submits a PR so reviewers can download the binary and test things quickly.

This was inspired from Prometheus's implementation where they appear to do the same thing:

https://github.com/prometheus/prometheus/blob/02501e097e3ed31cb34ec7a42963d41718c90010/.github/workflows/ci.yml#L109C1-L119C78

Then when there is a release or merge to main, all the architectures are built.

[electron0zero]

I okay with the split, but let's add this info as a comment as also link to Prometheus so we document the reason on why why we split the build.

[SuperQ]

Please take a look at YACE's CI.

This is a working example of Prometheus actions CI for an exporter.

[SuperQ]

These should be pinned to commit hash for supply chain security.

Suggested change

	uses: actions/[email protected]
	uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2

[SuperQ]

FYI, I have updated the Org shared secrets to included the required ENV vars for publishing.