K3d: [FEATURE] AUR Package - Link in README?

[JohnnyCrazy]

Scope of your request

Hi 👋

First of all, thanks for k3d and the continuous good releases! Really appreciate it for developing K8S applications locally on WSL2 and Linux :)

I'm maintaining an AUR Package rancher-k3d-bin for over 1/2 year now and would like to support it in the future as well. It uses the binaries published on github's releases page. If you're unfamiliar with the AUR:

The Arch User Repository (AUR) is a community-driven repository for Arch users. It contains package descriptions (PKGBUILDs) that allow you to compile a package from source with makepkg and then install it via pacman. The AUR was created to organize and share new packages from the community and to help expedite popular packages' inclusion into the community repository.

What do you think about a link to the package/a one line install instruction in the README? I can supply a PR if you agree

[iwilltry42]

Hi @JohnnyCrazy , thanks for the nice feedback :)
Ah, this is super cool :+1:
Feel free to post a PR for the README. Can we maybe integrate this in our deploy pipeline to automatically update the package?

[JohnnyCrazy]

See #231 for the link.

Regarding automated deploys: Yes, totally possible. However it requires some setup:

• Create an Account @ https://aur.archlinux.org/ and add it as maintainer of the package
• Generate a private key file for the account and add it as a secret to the travis config (An AUR package is a git repo and private/public keys are the only way to authenticate)
• Add the original PKGBUILD to this repo and replace some static settings with env variables (like pkgver)

• Have a deploy script similar to this:

  #!/bin/bash
  
  set -ex
  cd "$TRAVIS_BUILD_DIR/dist/arch"
  
  # Set up to run makepkg
  wget https://www.archlinux.org/packages/core/x86_64/pacman/download/ -O pacman.pkg.tar.xz
  tar -Jxf pacman.pkg.tar.xz
  bindir="$(pwd)/usr/bin"
  export PATH="$bindir:$PATH"
  export LIBRARY="$(pwd)/usr/share/makepkg"
  config="$(pwd)/etc/makepkg.conf"
  
  # Get the repo
  git config --global --add core.sshCommand "ssh -o StrictHostKeyChecking=false -i /tmp/deploy_key"
  git clone ssh://[email protected]/tectonic.git aur
  
  # Update it
  cp PKGBUILD aur
  cd aur
  /bin/bash "$bindir/makepkg" --config="$config" --printsrcinfo >.SRCINFO
  
  # Commit
  git add PKGBUILD .SRCINFO
  git config user.email "[email protected]"
  git config user.name "tectonic-deploy"
  git commit -m "Release $TRAVIS_TAG"
  
  # Deploy to AUR
  git push origin master
  

If that's okay from your side, I'm happy to supply a PR which does the heavy lifting. :)

[iwilltry42]

Hi @JohnnyCrazy , sorry for the long silence here. We planned to migrate the whole CI stuff to Drone a while ago already.
Now that it's finally done, I'll be happy to accept a PR for this on Drone :)
However, this will also require some work to be done on Rancher's side. I'll coordinate with them (AUR account + secrets in Drone) :+1:

[JohnnyCrazy]

I also lost the issue out of my sight ... 😅

So I recently went to the process of creating automatic AUR packages with github actions with one of my projects, Sp0. I guess drone already supports docker containers, so the setup would be quite similar.

There is one slight issue I couldn't solve yet: AUR packages do not contain any binary content. They should only tell how to get the binaries and how they should be installed. Thus, it needs a place where it can find the compiled binaries, which is a github release currently. This however is a problem when creating draft releases:

1 Push a new Tag --> Drone gets triggered
2 Build artifacts and draft GH release (Note: artifact download is only possible when the release is published!)
3 Build and push AUR Package with artifact checksums and download links to the GH release.
4 You guys edit the changelog and publish the release

Now, there is the problem: in the AUR, the package is already published while the GH release is still a draft. Users upgrading/installing between steps 3 and 4 will fail, since the artifacts can't be downloaded yet.

Didn't check your release pipeline yet, but if you draft releases, that could be a problem.

[iwilltry42]

First off: cool project :)

I think you're right there. Usually I draft a release (i.e. write up the release summary/changelog) and then wait for the release pipeline to push the artifacts and make it a real release (however, I think since the switch to drone something changed there). :thinking:

[JohnnyCrazy]

Thanks! :)

Looking at the drone pipeline, it doesn't have any draft setting on the release step. So when it finishes, the release will be published immediately. Not sure if you can manually pre-create a draft release and the step will automatically add the binaries to it?

Anyway, I think the problem regarding the time between AUR Release and published GH release can be neglected if the timespan is not too high. The only other solution I found would be a manual confirm step in the release pipeline, which is triggered after the GH release is published, but it's an additional manual step and not supported by drone.

[iwilltry42]

Yeah, when the drone pipeline finishes, it will be a real release always (and that's intended :+1: ).
So we can add the AUR step after the release step and should be good to go :thinking:
Additionally, we could add a command in the AUR step, which only continues if it could pull the release.

[JohnnyCrazy]

Sounds good 👍

I should have some spare time this week and will do some testing in a fork, hopefully with a PR as result :)