See https://docs.github.com/en/actions/sharing-automations/creating-actions/creating-a-docker-container-action

Used local action

see https://github.com/orgs/community/discussions/26245#discussioncomment-3250938

I thought the action name could be anything, but apparently it has to be action.yml. I created an actions folder just to make it clearer that this is an action, not a workflow

Used cd in a weird way but if it works it works

Few mistakes I made while porting over the code

Need it for the snapshot and publish outside the docker container

…build finishes

Caused by gradle files being left behind by the docker container. Having to install gradle two times for the linux job is a bit unclean, though.

Also added no-daemon to the gradle task used because only one gradle command is being executed in the docker container.

See https://github.com/koalaman/shellcheck/wiki/SC2164 for why this is good practice.

Using apt-get because apparently apt does not have a stable CLI interface. While apt install is probably safe, using apt-get will prevent the warnings in the log at least.

See https://askubuntu.com/a/990838

As for sudo, while it's not needed sudo also doesn't cause any harm and those commands technically do need root permissions and using sudo makes that clear.

Seems the zulu package I'm adding pulls in x11 which is unnecessary as we are running this in a headless setting.

whoops

Can't use sudo as the start as it needs to be installed first... so I just decided to not use sudo at all if it's not needed. But I'll keep the package install of sudo in case some other command needs it

We're installing zulu, so I don't think this is needed.

Hopefully this fixes the "Unable to delete directory build/generated/sources/annotationProcessor/java/main" error

Not using a daemon still because it's only two tasks.

Probably needed for the deploy to work properly. Honestly maybe I could move the deploy into the docker container but thing is it'd require passing in the secrets

I used https://docs.github.com/en/actions/sharing-automations/creating-actions/creating-a-docker-container-action#creating-an-action-metadata-file as a starting point, but don't need these inputs or outputs.

No longer doing it in multiple steps, so adding it to GITHUB_ENV won't really do anything, if it even works in the docker container right now which it probably doesn't.

Hopefully should prevent java 11 JRE from being installed, as zulu should provide what maven and ant needs.

Also specified default find path as recommended by https://github.com/koalaman/shellcheck/wiki/SC2185

The log seems to be massive for the docker step so hopefully this reduces it a bit.

Strangely I got an error while trying to download an artifact for no reason. So maybe updating actions could help? Either way we should be good to do this now that the job is no longer being run in a docker container with glibc 2.17

May need to audit these actions though.

The new setup-gradle seems to validate the wrappers, but strangely the wrappers from the sdl submodule fail to verify for some reason.

From TheOfficialGman's response to my questions here:
libgdx#23 (comment)

I think the main issue is still just verifying that publish works properly. Unfortunately publish still seems to build stuff in the runner even when the build command was run inside the container. Hopefully it doesn't cause any issues though.

Also added some comments I missed when porting the action steps to the script

…dering for apt-get

apt-get update is pretty noisy by default as there are a lot of lines for it reading the database. This should make it a bit quieter

I also noticed in the later part of the script -yq was before the install/update command so I made that consistent as well.

If not deploying the snapshot, there is no benefit to setting up JDK or Gradle, so we might as well skip those steps too to save a bit of time.

When I inspected the natives of a build from my branch and compared it to master, I noticed that while the master output-libs artifact only had one jar file in it (jamepad-2.30.0.0-SNAPSHOT-natives-desktop.jar) mine had 4 files in them (jamepad-2.30.0.0-SNAPSHOT.jar alongside other files with "workspace" at the start instead of jamepad for some reason, including the one with natives-desktop at the end). I figure this is because the build was being done before the deploy. As for the workspace name, it may be to do with how the container is configured...

It's only one gradle command being run in the job, so the daemon probably isn't needed.