Just created https://gitlab.wikimedia.org/repos/cloud/toolforge/packaging-pack/-/tree/main/ to package the pack cli, the tekton cli is just a binary too so you might be able to reuse all the scripts there (it was surprisingly complicated :/)

Actually, I've found that there is an upstream .deb that we can probably use instead of packaging it ourselves: https://github.com/tektoncd/cli#linux-debs

@aborrero suggested we add it to apt.wikimedia.org using Reprepro.

The upstream Debian repo doesn't seem to include a "Debian source package" that I think is required to follow the method at Building an unmodified third-party package for import.

I paired on this with @dcaro and I created a merge request that builds a deb package from the upstream binary tar.gz, similarly to what @dcaro did for the pack CLI.

We could also modify this build script to build from the upstream Golang source instead of using the precompiled binary, but that's more difficult, though we could probably reuse some of the scripts in the upstream repo.

Final question: when should we use the Toolforge Debian repository and when should we use apt.wikimedia.org?

In T317143#8332704, @fnegri wrote:

The upstream Debian repo doesn't seem to include a "Debian source package" that I think is required to follow the method at Building an unmodified third-party package for import.

The method to follow would be https://wikitech.wikimedia.org/wiki/Reprepro#Adding_a_new_external_repository

We don't need the source package for that. We already do this for kubeadm packages and is the recommended way to go.

Take a look at thirdparty/kubeadm-k8s-1-21 at modules/aptrepo/files/* in operations/puppet.git

Thanks, I'll try to follow that example and let you know if I get stuck.

What's your opinion on when to use the Toolforge Debian repo vs apt.wikimedia.org?

In T317143#8332760, @fnegri wrote:

Thanks, I'll try to follow that example and let you know if I get stuck.

What's your opinion on when to use the Toolforge Debian repo vs apt.wikimedia.org?

apt.wikimedia.org is the way to go. We use that one for things like mirroring external repos, like this case.

You mean mirroring the repo directly, as opposed to uploading the debian package right?

In that regard, is it a problem that the upstream is ubuntu-specific only? ("deb http://ppa.launchpad.net/tektoncd/cli/ubuntu jammy main")

In T317143#8333390, @dcaro wrote:

You mean mirroring the repo directly, as opposed to uploading the debian package right?

In that regard, is it a problem that the upstream is ubuntu-specific only? ("deb http://ppa.launchpad.net/tektoncd/cli/ubuntu jammy main")

Yes, mirroring the repository. If the tekton repo contains, say, a 1000 packages, reprepro has the ability to filter packages on demand. But on a quick check, I think we will be fine just mirroring it in its entirety.

Regarding the ubuntu thing, I think we will be fine. We do the same for the thirdparty/kubeadm-k8s-1-21 component. We mirror an ubuntu repository. You can do a quick local check somewhere (curl + dpkg -i) to see if the package installs fine in our toolsbeta VMs and that's pretty much it.

BTW, suggestion for the new component name: thirdparty/tekton.

Yes, mirroring the repository. If the tekton repo contains, say, a 1000 packages, reprepro has the ability to filter packages on demand. But on a quick check, I think we will be fine just mirroring it in its entirety.

There's only a single package yep xd

Note that that requires adding the extra repo (from apt.wikimedia.org) to the VMs that need that package too.

In T317143#8334956, @dcaro wrote:

Note that that requires adding the extra repo (from apt.wikimedia.org) to the VMs that need that package too.

This is OK. The canonical way of doing that in puppet is using the apt::package_from_component resource.

Change 845483 had a related patch set uploaded (by FNegri; author: FNegri):

[operations/puppet@production] Add Tekton deb repository

https://gerrit.wikimedia.org/r/845483

@dcaro do we need the package to be available in buster, or bullseye is enough?

I think buster might be needed too yes (current bastion hosts).

Change 845483 merged by FNegri:

[operations/puppet@production] Add Tekton deb repository

https://gerrit.wikimedia.org/r/845483

Change 849033 had a related patch set uploaded (by FNegri; author: FNegri):

[operations/puppet@production] Fix reprepro config for thirdparty/tekton

https://gerrit.wikimedia.org/r/849033

Change 849033 merged by FNegri:

[operations/puppet@production] Fix reprepro config for thirdparty/tekton

https://gerrit.wikimedia.org/r/849033

Change 849044 had a related patch set uploaded (by FNegri; author: FNegri):

[cloud/toolforge/toolforge-cli@main] Use new tektoncd-cli package from apt.wikimedia.org

https://gerrit.wikimedia.org/r/849044

Change 849047 had a related patch set uploaded (by FNegri; author: FNegri):

[operations/puppet@production] Add new tekton package to WMCS bastions

https://gerrit.wikimedia.org/r/849047

Change 849044 merged by jenkins-bot:

[cloud/toolforge/toolforge-cli@main] Use new tektoncd-cli package from apt.wikimedia.org

https://gerrit.wikimedia.org/r/849044

Change 849047 merged by FNegri:

[operations/puppet@production] Add thirdparty/tekton repo to WMCS bastions

https://gerrit.wikimedia.org/r/849047

Change 850506 had a related patch set uploaded (by FNegri; author: FNegri):

[cloud/toolforge/toolforge-cli@main] Bump version to 0.2.1

https://gerrit.wikimedia.org/r/850506

The Tekton CLI has been updated in toolsbeta-sgebastion-05:

fnegri@toolsbeta-sgebastion-05:~$ tkn version
Client version: 0.27.0
Pipeline version: v0.33.2

Before this ticket is resolved, I want to merge this patch that is currently blocked on T321915.

Change 850506 merged by jenkins-bot:

[cloud/toolforge/toolforge-cli@main] Bump version to 0.2.1

https://gerrit.wikimedia.org/r/850506