Set up automated testing in CI/CD (GitHub Actions Workflow)

[volkertb]

Earlier this week, GitHub announced more powerful runners for open source projects. In addition to twice the number of CPU cores, twice the RAM and vastly more storage, these new runners also add support for nested virtualization, which will allow hypervisors such as QEMU to run in GitHub Actions much faster, since it will no longer have to resort to CPU emulation in software.

That's particularly cool, because a while back I created the cicd-qemu-dos-docker project, a Docker container image that can be used to perform operations in a (Free)DOS environment as part of a CI/CD pipeline. I am going to update that project so it takes advantage of the availability of KVM, the Linux hypervisor interface, which the new free-tier GitHub runners should now be exposing.

Subsequently, I can then use that image to implement automated tests (on every commit or merge to the main branch), to verify that the basic functionality of SBEMU works. Of course, these automated tests only test SBEMU against the emulated AC'97 ICHx and Intel HDA devices of QEMU, so this wouldn't be a complete substitute for actual hardware testing, but it will be useful as a basic automated sanity and regression test.

Assigning this one to myself.

[crazii]

I merged the PR and it doesn't build, after installing some packages (it seems packages are no installed, wget, even sudo), it still fails at mount: /tmp/mnt: mount failed: Operation not permitted. https://github.com/crazii/SBEMU/actions/runs/7600508438/job/20698842875#step:6:406 I'm not familiar with it and not sure what happened, Does the new runners environment have limited access?

[volkertb]

@crazii LOL, PR #76 wasn't ready to be merged yet. :laughing: I guess that's on me. The Actions seemed to pass (everything was green), but that's because the error codes from the batch job in the DOS VM weren't being propagated to the job that was running the Docker container.

I guess I should have marked the PR as "draft" or opened a discussion to block the merge while I worked on it further. Sorry about that. I worked on it until late in the night, and I forgot to do that.

The errors you just reported above are weird, though. I didn't run into those when the actions while I was working on the PR yesterday. I'll look into that, and open another PR to resolve all of this. I'm not sure if I'll get enough time for that today, though.

[volkertb]

Hmmm... That's workflow 01, building the release artifacts. Did I break that one while working on workflow 02? I guess that would explain why I didn't catch it before it was merged.

Ah, but now it's blocking all releases, so I guess I'll have to prioritize this a little bit. :grimacing:

Let me eat some breakfast and then take a look at this.

[volkertb]

@crazii I see you recently committed some changes to 01-build-and-release.yml and build-release-artifacts.sh, and that seems to be the cause of the errors you reported, since this PR didn't make any change to that workflow and script.

What were you trying to change or fix? Maybe I can help. Thanks.

[crazii]

OK, just a little misunderstanding, I should confirm before merge. No hurry, hjnijlunsing is able to perform a local build without the GitHub release.

[crazii]

The build-release-artifacts.sh reports error on such packages not found: wget shasum unzip sudo I tried installing them in the 01-build-and-release.yml and turns out good. and build-release-artifacts.sh finally failed with mount

[crazii]

The errors exist before I changes anything on build-release-artifacts.sh or 01-build-and-release.yml, but right after I merged this one: https://github.com/crazii/SBEMU/actions/runs/7599122971

[volkertb]

@crazii Okay, this error after revert #78 is even weirder: https://github.com/crazii/SBEMU/actions/runs/7601015961/job/20699920684

I do know that newer (and much better) GitHub runners were rolled out last week for the free tier, which actually led me to create the PR in the first place. But perhaps the changes to these upgraded runners may have introduced some other incompatible changes. I'll have to research this further.

Still weird that this started to become an issue exactly when you merged my PR.

[crazii]

I not familiar with Github Actions, so I'll leave this to you :). And for now reviews from me is not likely gonna work. I'll take some time to learn more about it in the future. :)

[volkertb]

@crazii Can you maybe do the following:

• Stash your current uncommitted and unsaved changes
• Check out main (if you're not currently working directly on main)
• git reset --hard 1d57f760f9e0b502f949b43b5e2f73b4eee14e60 (the last commit with a successful release pipeline)
• git cherry-pick b05b5488ccde91d1e226819bae6adee7dd18342c (reapply CMI: fix DMA buffer alignment.)
• git cherry-pick c9df20688c3964ec9d9dd034befd29f3c5f00e6e (reapply CMI: remove sbpro mixer as the datasheet is misleading. add log for b…)
• git push --force (you may have to temporarily unprotect the main branch in the GitHub settings for this project to perform this command)

[crazii]

OK, you mean delete the merged PR and reset to the one previously commit & recommit the ones after it, I can try.

[volkertb]

@crazii Yes, by doing a hard reset to an earlier commit, you are effectively rewinding the respository to an earlier commit, i.e. the last one for which the release pipeline was successful. And with those cherry-picks, you can then reapply your two CMI fix commits (and only those) on top of that "last known good state".

[crazii]

It's OK now after reset before merging the PR.

[volkertb]

Nice! At least the pipeline is working again. I'll rebase my test action branch on top of this state and create another (draft) PR. Thanks!