Build Debian packages and upload them to Forgejo's repository #996
Labels
No labels
Bug
Cherry-picking
Database
Dependencies
Dependencies/Renovate
Difficulty
Easy
Difficulty
Hard
Difficulty
Medium
Documentation
Enhancement
Good first issue
Help wanted
Inherited
Matrix/Administration
Matrix/Appservices
Matrix/Auth
Matrix/Client
Matrix/Core
Matrix/Federation
Matrix/Hydra
Matrix/MSC
Matrix/Media
Meta
Meta/CI
Meta/Packaging
Priority
Blocking
Priority
High
Priority
Low
Security
Status/Blocked
Status
Confirmed
Status
Duplicate
Status
Invalid
Status
Needs Investigation
To-Merge
Wont fix
old/ci/cd
old/rust
No milestone
No project
No assignees
4 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
continuwuation/continuwuity!996
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "ci-deb"
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?
This uses the existing
cargo-deb
metadata.debian_version
for consistencyWIP: Build Debian packages and upload them to Forgejo's repositoryto Build Debian packages and upload them to Forgejo's repositoryThis should be squash-merged.
aab4c5eaee
dd932e9824
dd932e9824
a7cd4e9554
PR is likely to be superseded by a monolithic release workflow, keep open for now
a7cd4e9554
b8dfab0236
This wants to be merged, just with a limit like this to avoid it running on every main/branch push:
93339a8e75
d7bbac9452
LGTM, thank you! Please squash though 🙏😅
@ -0,0 +17,4 @@
runs-on: ubuntu-latest
strategy:
matrix:
container: ["ubuntu-latest", "ubuntu-previous", "debian-latest", "debian-oldstable"]
is it not better to pin to specific releases rather than just "latest" and "prev" when it comes to builds like this?
these are profiles on the runner, so technically the one holding the runner is pinning the version - i could set up specific pinned runner profiles for these builds though.
ah nvm yeah that makes sense
Technically if we want to pin the base image we should be using the
container:
key@ -0,0 +95,4 @@
- name: Install cargo-deb
run: |
if command -v cargo-deb &> /dev/null; then
echo "cargo-deb already available"
Is this step necessary? is it not a case of "It's in the base image or it's not"?
some images may have it and some may not, i'm a fan of optional installs that skip when not required 🙂
nothing to hold up a merge on from my pov