Set up GitHub actions

[zjeffer]

No description provided.

[Duckonaut]

I see you're working on this, I'm thinking it would be a good idea to verify against Hyprland git and maybe two latest tagged releases (arbitrary number, but convenient because that's how many we have pinned right now 😄). I'll play a bit with it to make it work, should probably be 3 separate workflows

[zjeffer]

We could maybe make two types of workflows:

1. Nightly workflow: builds the latest x pins and the current git version of Hyprland and this repo.
2. Pull request workflows: builds the pull request branch with the latest hyprland-git version. Optionally we could require the pull request to successfully build before being able to merge.

[zjeffer]

Right now I'm stuck at the checkout step, though. For some reason the step doesn't have appropriate permissions?

This is perhaps because I'm using my own image of Arch + Hyprland and changing the user in that Docker image?

[Duckonaut]

Could be, I'd assume the checkout action runs as some github user that's assumed to exist in the "standard" images

[Duckonaut]

Is there a reason for using checkout@v2 though? I see there's checkout@v4 out by now

[zjeffer]

@Duckonaut In this commit, I added an action that would build the base Dockerfile every night, and pushes it to docker hub. I'd rather not put this image on my own docker hub account, though, because then I'd have to give you an access token to add to the GitHub secrets ;)

Would you be willing to add your docker hub username and access token to the GitHub secrets of this repo, so we can build and publish this image automatically? I assume this is your account: https://hub.docker.com/u/duckonaut ?

With this continuously updated image, we can ensure we're building hyprland and the plugin from the most recent version of Arch.

[Duckonaut]

That makes sense. I'll put the credentials in the secrets and we'll see how it goes

[Duckonaut]

Alright, done. Change the image to pull and see if it works correctly

[zjeffer]

It works :)

[zjeffer]

I think I'll do the hyprpm pins in another PR, for now this can be merged IMO

[Duckonaut]

I can see that, looking good! Github actions really is weird, good that you've made it work

[zjeffer]

I got a lot of help from GitHub copilot 😉 (that's why it suggested checkout@v2 😅)

[zjeffer]

I'm wondering how we would do the pins thing... Say we want to build the plugin for the latest two commits (currently v38.1 and v39.1), we'd have to install Hyprland's dependencies that work with those versions of Hyprland, and then compile Hyprland from the release tag. It seems quite difficult to find the correct versions of the dependencies that work for those Hyprland releases.

Maybe we have to find a way to not have to build hyprland, but just make sure the headers are included so the plugin can build? That way we could just clone the Hyprland repo without having to install anything.

[Duckonaut]

I'm wondering how we would do the pins thing... Say we want to build the plugin for the latest two commits (currently v38.1 and v39.1), we'd have to install Hyprland's dependencies that work with those versions of Hyprland, and then compile Hyprland from the release tag. It seems quite difficult to find the correct versions of the dependencies that work for those Hyprland releases.

Maybe we have to find a way to not have to build hyprland, but just make sure the headers are included so the plugin can build? That way we could just clone the Hyprland repo without having to install anything.

It would be pretty tough to resolve the dependencies for past releases. I guess we could drop it and just test on -git and latest tagged in Arch repositories, Arch installs headers and I think realistically for now it's all we need to care about.

Alternatively, we could set up a scheme with Docker images. We'd have 3 docker images

• git, rebuilt daily from hyprland-git
• latest, rebuilt on Hyprland major version change from Arch packages
• past, which would just be the previous latest moved to a different tag.

Or we could mess with Nix for this, it would resolve the dependencies for Hyprland correctly, and we could build Hyprland with Nix on Arch, then export the headers to the standard location.