[Slackbuilds-users] stop mirroring to github~
Andrew Clemons
andrew.clemons at gmail.com
Tue Aug 19 12:52:49 UTC 2025
On 2025-08-19 07:05:36 +0200, slackbuilds-users at slackbuilds.org wrote:
> [...]
To close the loop on the questions:
> But seriously, why is GitHub used? Is it because that it's gratis or
> have some sort of CI? I for one am willing to donate and/or contribute
> for setting up a CI on a federated server. Although I don't have much
> experience in that area yet.
It's just a mirror. The canonical git repo is always
git.slackbuilds.org.
As far CI, I run the build box that we use to verify weekly submissions.
It's my machine that I pay for and it’s running Slackware (and Jenkins
LTS which I maintain on slackbuilds.org¹). It doesn't care which git
repo has the change to build.
For my own submissions, I most often simply push them to my branch on
git.slackbuilds.org then trigger a build from the Jenkins rest api. That
checks out my branch there and then sends an email with the build result
and sbopkglint output some time later.
Maintainers can open PRs on the github mirror. For this, I also run a
lambda function (running slackware of course) in my AWS account which
operates as a webhook. Willy or whoever can comment on the PR and the
lambda triggers my Jenkins to build the package, this time checking out
the PR from github instead. Instead of emailing the results, it posts
them as a comment on the PR.
Other maintainers open MRs on the gitlab mirror. Another lambda operates
as a webhook for it, receiving comments on the MR which triggers my
Jenkins to build the package, checking out the code from gitlab instead,
posting the results as a comment on the MR.
If Willy or someone one day makes a codeberg mirror or something else,
I'll probably setup a web hook there to do the same thing.
Why is there a github or gitlab mirror? Some people find it convenient
to submit updates through a PR/MR workflow instead of zipping up a
tarball and uploading it. Plenty of maintainers still do that and that
will always be possible.
As far as the tarball submissions, to simplify reviewing the diffs and
triggering builds for each while keeping track of failures, we have two
scripts to open PRs/MRs for each submission and automatically trigger
builds for them. They are in my repo here². Willy does all the hard work
here every week and I think he finds working on github PRs most
convenient, so they usually end up getting opened as PRs and checked
there. The changes will end up on github or gitlab after the public
update anyway when the mirrors are synced.
We could just stack the diffs one one of our branches on
git.slackbuilds.org and trigger the builds on Jenkins through the rest
api with a similar script, but Willy would then have to sort through the
emails, rebase and drop commits for failed builds, keeping track of the
status of each submissino etc. I defer to him for what is most efficient
for him to churn through all the submissions every week. I've just tried
to build some tooling to make it as simple as possible.
Happy to answer any other questions related if I can.
Cheers,
Andrew
¹ https://slackbuilds.org/repository/15.0/system/jenkins/
² https://codeberg.org/aclemons/sbo-bot/src/branch/master/bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.slackbuilds.org/pipermail/slackbuilds-users/attachments/20250819/b896b293/attachment-0001.asc>
More information about the SlackBuilds-users
mailing list