Migrate from CircleCI

[jonnybot0]

We plan to move off the CircleCI system.

We can use GitHub actions for a lot of things.

If we need more than that, we can move onto the Apache Software Foundation's Jenkins instance. Our rationale for using that is that a couple of the current maintainers (@Poundex and @jonnybot0) have some background with Jenkins, which also has a nice Groovy DSL for jobs.

The Apache Guide on Jenkins says we'll need access from the PMC. It looks like I can currently login to Jenkins and even create objects in the Groovy section.

Will look at replicating many of the build steps in Circle CI to GitHub actions first, as that's the least friction

[jonnybot0]

Did a basic PoC git GitHub actions to run the check job, which seemed to work okay. https://github.com/apache/groovy-geb/actions/runs/12188231782

I had a go at using Reusable actions for much of the rest, but I don't think I've quite got it right. See:

• Failed run: https://github.com/apache/groovy-geb/actions/runs/12188668188
• Source: https://github.com/apache/groovy-geb/tree/refs/heads/task/213-github-actions-for-ci
• Docs: https://docs.github.com/en/actions/sharing-automations/avoiding-duplication

I'll need to dig into things a bit more later. Leaving this note here for future me to pick up where I left off.

[paulk-asert]

The publishing of snapshots is now handled by this Jenkins build (may require asf login):

https://ci-builds.apache.org/job/Groovy/job/Geb%20snapshot%20build/

Snapshot artifacts are published here:

https://repository.apache.org/content/repositories/snapshots/org/apache/groovy/geb/

Note: I moved a couple of PRs fairly quickly, so some of this may change once the dust settles and folks have a chance to review.

[jonnybot0]

Hey, Paul. I actually appreciate you moving some of this quickly. Wrapping up for the end of year left me with relatively little time for review, but I'm going to be doing some catch-up today. If there's any feedback that I can quickly action, I'll probably just raise a PR. If it needs more discussion, I may raise a post or comment here as appropriate.

[jonnybot0]

So, running check pretty well covers everything that was in the manual and check steps. That step is definitely taking a lot longer, so it may be needful to break it up into distinct steps as it was in CircleCI.

[paulk-asert]

The website is now generated from a Jenkins build:

https://ci-builds.apache.org/job/Groovy/job/Geb%20to%20Groovy%20dev%20website/

See:

a8db6a0

I am sure it would be simpler using GitHub actions but I just replicated what we do for the Groovy build for now. I haven't done a lot of extensive testing, so might need some fine tuning if we find any issues.

We should be able to remove CircleCI now? Though I haven't cross-checked we run all tests. At least it is happy for now:

[jonnybot0]

So, https://ci-builds.apache.org/job/Groovy/job/Geb%20to%20Groovy%20dev%20website/ only publishes the Groovy website, right? And https://ci-builds.apache.org/job/Groovy/job/Geb%20snapshot%20build/ only publishes the snapshot build.

Seems we still need a build to run the whole test suite that CircleCI is currently doing. GitHub actions is running ./gradlew -Pci --no-daemon --no-build-cache check -x rat . I did a --dry-run of that task locally, just to see what all get runs and make sure it covers the same ground as the above checks.

check

Command: ./gradlew --no-daemon --max-workers 4 --parallel -Pci module:check internal:check integration:check doc:site:check --continue
Only additional Gradle task this would run that the GitHub Actions check wouldn't was the rat task, which we run in license-check.yml. So that's covered by GitHub actions (build-check.yml and license-check.yml for rat).

manual

Command: ./gradlew --no-daemon --max-workers 4 --parallel -Pci :doc:manual-snippets:check :doc:manual-snippets:fixtures:check :doc:manual-snippets:real-browser:check :doc:manual:build :doc:asciidoctor-extension:check

This runs :doc:manual:assemble and :doc:manual:build. While those are covered by the Geb website deployment, we should probably have them as GitHub actions to make sure we're not breaking the manual on a PR. I'll work on pushing up a PR to do that in a separate action.

dockerised-cross-browser

This one definitely isn't running in GitHub Actions or Jenkins at the moment. I'll include that with the manual work.

local-cross-browser

Also not run currently. Again, should be doable as a GH action.

I'm going to assume based on that survey that probably the rest (non-ie, ie, and saucelabs) aren't run in anything we've got either. Seems like a good contribution for a Friday afternoon. :)

[jonnybot0]

Had a go at setting up a Jenkins build to run the SauceLabs tests this afternoon. https://ci-builds.apache.org/job/Groovy/job/Geb%20Cloud%20Browser%20Testing/

Went for Jenkins purely because it was easier for me to add the necessary credentials as saved secrets there. Happy to do this as a GitHub Action if folks would strongly prefer it. Will also need to figure out what the right trigger is for testing these external integrations. My hunch would be "on pull request and before release, but not on every push." Not 100% sure how to set that up in Jenkins.