Make GitHub Actions build a Debian package for download (fixes #34) #37
Conversation
$ wget https://deb.debian.org/debian/pool/main/k/kdbg/kdbg_2.5.5-3.debian.tar.xz $ tar xf kdbg_2.5.5-3.debian.tar.xz $ git add debian/
|
Why does the clang-17 job fail? Please justify why the 2.5.x patches are not needed anymore, in particular the one that claims to fix encoding. ("Testing without the patches shows that they are not necessary anymore" is fine, but if you know more, then I'd appreciate if you would add that knowledge in the commit message.) |
- 10_fix_check_include_files.patch Fixed by commit d5745f3 already. - 11_fix_changelog_encoding.patch New patch of value, applied in a separate follow-up commit in order to allow proper author information on commit level.
hartwork
force-pushed
the
debian-package
branch
from
be5d71f
to
bf0a140
Compare
|
Hi @j6t, glad you like this pull request 😃
The log says it all: the CI depends on working Internet access and the availability of a few services and one of the downloads failed with error
Sure! It turns out that:
Okay nice, so a free "bugfix", good catch! Commit message extended and fix applied now, pushed. Looking forward to the next round of review 🙏 |
|
@j6t any chance you could review/merge this over the weekend? |
|
@j6t thank you! 🙏 |
|
Thank you for the contribution. How to move forward with this? How do users know that there are build products? Where do they find them? How do they know what to download? |
@j6t I'm glad you see value in it.
Adding a sentence to the top of the readme may work. Arguably they could be called "nightly builds Debian packages" or something like that, although technically "nightly" is not correct.
I would suggest https://github.com/j6t/kdbg/actions/workflows/debian_package.yml?query=branch%3Amaster for a link and add "at the bottom of each CI run page" as an additional hint or instruction. If you feel like converting the readme to Markdown, an annotated screenshot could be added with an example. Something like this:
The only file is named What do you think? |
|
I would have expected that things are much easier to find. Why do we do all this if the results are so hidden? I cannot believe that other projects provide Debian packages in this way. |
@j6t would wish it was easier to find myself. I believe it's intentional to some extent. I should also note that CI run logs and artifacts are not kept forever. Another reasons why it's good that we're building at least once a week.
@j6t for releases, attaching binaries to a page below https://github.com/j6t/kdbg/releases would be one way to go. We can adjust the CI use a slight different versioning scheme when building Git tags and you can download and attache the results to a release directly. But you're not using GitHub releases yet. Here's what a release with (source and) binary attachments liks like: https://github.com/libexpat/libexpat/releases/tag/R_2_5_0 Regarding other projects: many have no packages at all, the most important ones don't need any because they are right in Debian, everyone else does all sorts of things. We could make the CI do a lot more like creating GitHub release with build files attached automatically, but that will require quite some work, credentials, and so on — it's beyond the scope of what I want to volunteer for.
Having hard to find files that you can point people to is better than no files, right? Why so negative? |
It has some value, yes. |
Fixes #34
Review on commit level (rather than whole-diff level) is advised.
PS: The failed job
clang-17below should go all green after retry.