Replace current build infra with Github Actions

[danielmarbach]

I think it would be great for transparancy and evolvability perspective to switch to github actions

For example

https://github.com/marketplace/actions/setup-rabbitmq-with-username-and-password

[stebet]

Makes sense. How hard is it to integrate rabbitmqctl into those?

[stebet]

If that's not possible, it's also possible to set up a CI build on Azure DevOps using the free-tier against the MS-hosted build agents and execute the builds in a container, including tests if more control is needed.

[asbjornu]

It's possible to use a Docker container directly in GitHub Actions with uses: docker://rabbitmq:3.8.9-management-alpine for a step or the following for a job:

container:
  image: rabbitmq:3.8.9-management-alpine

(I'm just a bit unsure about the exact syntax). It's also possible to bundle a Dockerfile and do docker build and docker run directly. Azure DevOps should not be needed.

[stebet]

This can be done with service containers. I have a PoC running, will get it running and then post my workflow yaml :)

[asbjornu]

Just for the fun of it, I did a spike in asbjornu#1 that just replaces CI, but keeps the scripts and process. It works for Linux, not yet sure for Windows.

[stebet]

.github/workflows/dotnet-core.yml
name: .NET Core

on:
  push:
    branches: [ master ]
  pull_request:
    branches: [ master ]

jobs:
  build:

    runs-on: ubuntu-latest
    services:
      rabbitmq:  
        image: rabbitmq:3.8.9-management
        ports:
         - 5672:5672
         - 15672:15672
        
    steps:
    - uses: actions/checkout@v2
    - name: Setup .NET Core
      uses: actions/setup-dotnet@v1
      with:
        dotnet-version: 3.1.x
    - name: Build
      run: dotnet build --configuration Release
    - name: Test
      run: dotnet test --configuration Release --framework 'netcoreapp3.1' --no-build
      env:
        RABBITMQ_RABBITMQCTL_PATH: DOCKER:${{job.services.rabbitmq.id}}

This works and might be a good initial step for CI builds (doesn't set SourceLink etc. but compiles and runs the tests targeting netcoreapp3.1).

[asbjornu]

That looks good, @stebet! If build.sh, build.bat, run-test.sh and run-test.bat is supposed to be kept, shouldn't it be a point to use these in the tests as well so they don't become stale and drift into oblivion? An alternative is of course to delete them.

[stebet]

Yeah, I merely meant this as an intermediate step to get things started. If GitHub Actions is to be used instead for building and running the tests they might very well be redundant.

This small action works fine for PR validation (builds code, runs tests), then if successful might trigger another build that properly builds and runs tests on all supported platforms.

[asbjornu]

Got it. Should a PR delete appveyor.yml and .travis.yml or do you want to keep those around still, @stebet?

[michaelklishin]

Team RabbitMQ has internal Concourse pipelines that rely on those scripts. We'd like to keep them for now, they are small and not too painful to maintain.

Our team has been moving RabbitMQ itself to Actions for several months now (currently RabbitMQ core 3.9/master uses Actions), so we would welcome this change for this library.

[asbjornu]

Thanks for the info, @michaelklishin. How about .travis.yml? Any reason to keep that after a GitHub Actions Linux workflow is added?

[stebet]

It'd think that the .travis.yml would be unnecessary at that point since that is the Linux CI build.

[michaelklishin]

Travis CI has served us well but if switch to Actions, there is no reason to keep it. I assume GitHub Actions has all the same GitHub PR integrations a contributor would expect :) Travis has been adopted for external contributors, not so much the core team.

[asbjornu]

Ok, cool. #952 submitted, replacing Travis CI with a GitHub Actions workflow for Linux. We still need to figure out what to do with a Windows build.

[lukebakken]

I don't think we've had any issues using AppVeyor for Windows builds.

[bording]

Ok, cool. #952 submitted, replacing Travis CI with a GitHub Actions workflow for Linux. We still need to figure out what to do with a Windows build.

It sure would be nice if there was a Windows RabbitMQ docker image we could use with GitHub Actions.

[asbjornu]

I don't think we've had any issues using AppVeyor for Windows builds.

Wouldn't it be beneficial to have everything in one place on GitHub Actions, though?

[lukebakken]

I recently set up a Windows build for our .NET stream client -

rabbitmq/rabbitmq-stream-dotnet-client#70
rabbitmq/rabbitmq-stream-dotnet-client#76

I'll do the same here. Note that docker is not supported on Windows GHA runners but it's easy enough to install Erlang and RabbitMQ on the Windows CI runner, then cache the installers.