4
9
Fork
You've already forked libchewing
3

Automatically generate DEB and RPM packages for testing #541

Open
opened 2024年05月17日 06:45:38 +02:00 by hiunnhue · 3 comments
hiunnhue commented 2024年05月17日 06:45:38 +02:00 (Migrated from github.com)
Copy link

Is your feature request related to a problem? Please describe.
Describe the solution you'd like

Is it possible to configure GitHub Actions or another method to automatically generate DEB and RPM packages for testing purposes? This would allow users to easily install them for testing, eliminating the need for manual builds (and potentially resolving build errors) on their machines.

As I recall, libchewing used to have an Ubuntu PPA that automatically generated the latest DEB package for users after each commit or when a beta version was released.

**Is your feature request related to a problem? Please describe.** **Describe the solution you'd like** Is it possible to configure GitHub Actions or another method to automatically generate DEB and RPM packages for testing purposes? This would allow users to easily install them for testing, eliminating the need for manual builds (and potentially resolving build errors) on their machines. As I recall, libchewing used to have an Ubuntu PPA that automatically generated the latest DEB package for users after each commit or when a beta version was released.
kanru commented 2024年05月17日 06:53:23 +02:00 (Migrated from github.com)
Copy link

I was thinking about that too. With CMake we can easily generate binary packages, they will not be compliant with distro standards though. So we should warn about that.

Do you want to have per release binary or per commit? Which is more useful?

I was thinking about that too. With CMake we can easily generate binary packages, they will not be compliant with distro standards though. So we should warn about that. Do you want to have per release binary or per commit? Which is more useful?
hiunnhue commented 2024年05月17日 14:27:03 +02:00 (Migrated from github.com)
Copy link

I am not sure about this ... but would it be inefficient to generate binary packages for every commit, especially considering minor changes like typo fixes or documentation updates?

Perhaps we could automate binary package generation for tags (like Alpha, Beta, RC, etc.) and allow for manual triggering on specific commits when necessary, namely, when you would like to call for testers.

Alternatively, we could implement scheduled builds (daily or weekly) that run whenever there's a new commit. This might also be useful for bug triage, as there wouldn't be too many commits between builds.

Unlike PPAs, problematic packages are immediately pushed to users via PPAs. This allows users (volunteers) to immediately report any errors they encounter.

I am not sure about this ... but would it be inefficient to generate binary packages for every commit, especially considering minor changes like typo fixes or documentation updates? Perhaps we could automate binary package generation for tags (like Alpha, Beta, RC, etc.) and allow for manual triggering on specific commits when necessary, namely, when you would like to call for testers. Alternatively, we could implement scheduled builds (daily or weekly) that run whenever there's a new commit. This might also be useful for bug triage, as there wouldn't be too many commits between builds. Unlike PPAs, problematic packages are immediately pushed to users via PPAs. This allows users (volunteers) to immediately report any errors they encounter.
kanru commented 2024年05月17日 15:35:28 +02:00 (Migrated from github.com)
Copy link

Sure, I can attach binary packages for tagged releases.

We can also setup weekly builds, though I'm not sure if we will have that many changes 😅

Sure, I can attach binary packages for tagged releases. We can also setup weekly builds, though I'm not sure if we will have that many changes 😅
Sign in to join this conversation.
No Branch/Tag specified
master
release/0.13.x
push-qlrtqulwmpmp
push-wtuvoynpwosl
release/0.10.x
release/0.8.x
optimize-conversion
refactor-trie-loader
v0.13.0
v0.12.0
v0.12.0-alpha.1
v0.11.0
v0.11.0-alpha.1
v0.10.3
v0.10.2
v0.10.1
v0.10.0
v0.9.1
v0.9.0
v0.9.0-rc.3
v0.9.0-rc.2
v0.9.0-rc.1
v0.8.5
v0.8.4
v0.8.3
v0.8.2
v0.8.1
v0.8.0
v0.8.0-rc.4
v0.8.0-rc.3
v0.8.0-rc.2
v0.8.0-rc.1
v0.7.0
v0.7.0-rc.2
v0.7.0-rc.1
v0.6.0
v0.6.0-rc.2
v0.6.0-rc.1
v0.5.1
v0.5.0
v0.4.0
v0.3.5
v0.3.4
v0.3.3
v0.3.2
v0.3.1
v0.3.0
v0.2.7
v0.2.6
v0.2.5
v0.2.4
Labels
Clear labels
dictionary
duplicate
fixed
0.11.0

Archived

fixed
0.13.0
refactoring

Archived

rewrite in rust
Might be fixed by the rust rewrite
thirdparty
arch
aarch64
系統架構是 Aarch64
arch
x86_64
系統架構是 x86_64
cannot reproduce
無法重現問題 Cannot reproduce the issue
contribution welcome
歡迎來幫忙 Contributions are very welcome, get started here
duplicate
重複的問題回報 This issue or pull request already exists
good first issue
適合新手 Interested in contributing? Get started here.
help wanted
需要高手相助 Need some help
invalid
回報的問題無效 Something is wrong
kind
bug
有東西不正常運作 Something is not working
kind
doc
加強文件說明 Enhance documentation
kind
enhancement
新功能 New feature
kind
mega issue
同一個問題回報中包含多個問題 Multiple issues reported
kind
question
只是問問題 Asking a question
needinfo
需要更多資訊 More information is needed
os
apple
作業系統是 MacOS 或 iOS
os
linux
作業系統是 GNU Linux
os
windows
作業系統是 Windows
to be determined
還未被說服有需求 Can't decide whether this is needed
upstream
跟上游軟體相關 Related to an upstream repository, already reported there
wontfix
我們決定不處理 Won't be fixed
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
chewing/libchewing#541
Reference in a new issue
chewing/libchewing
No description provided.
Delete branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?