feat(ci): deb package on release

[Mte90]

Ref: #289

So I did an update to the toml file, the ci will use cargo deb to generate the package, tested locally and works.

I am not sure how the CI works, I think that I am putting the file in the right path but I am not sure if it is the right job.

[Ph0enixKM]

I've just generated a new release on my testing forked repository. The action failed to add the debian installer to the Assets under the release. Here is what assets it generated:

[Mte90]

As I can see from the log https://github.com/Ph0enixKM/amber-workflow-tests/actions/runs/11464290559/job/31900143129 the deb package was generated.

I think that the issue is that I have to specify the file to upload because doesn't upload all the files in a specific folder.

[Mte90]

@Ph0enixKM can you try now?

[Ph0enixKM]

@Mte90 I'll finish fixing master and then I'll try it again

[Ph0enixKM]

Let's merge this fix (#535) and then I'll test this branch.

[Ph0enixKM]

After testing the new changes, it seems that it still does not work. I got no .deb in the assets section of a release.

1. I just read this change and you have written this in the plan phase of the build setup. It would make more sense to move it into the building phase called build-global-artifacts.
2. What arch do you want to compile the deb for? I see that the default runner architecture is x86_64-unknown-linux-gnu so it will probably compile to that. Please add compilation triple to the filename. You get get the target triple like so TARGET_TRIPLE="$(rustc -Vv | awk '/^host/ { print $2 }')". Should we support ARM?
3. I think that you don't upload the generated .deb to the assets artifacts anywhere in the pipeline.

Here are the changes that should get this to work:

[Mte90]

I did that changes, automatically the file is created with the architecture where it is compiled.

[b1ek]

i don't get it. i thought we still haven't discussed if it is our responsibility to maintain packages

i am making a code suggestion here so that this will be a discussion so it can be minimized when resolved

ref #294

[b1ek]

can this at least be in a different repo in the organization? i'm pretty sure there is a million ways to get the tool to pull code from it

[Mte90]

Usually projects release the package for the various distro, in a different repo I think that is the case when the project will grrow.
Right now I can be the debian maintainer, as the package it is just the binarry generated from rust in a dedicated compressed package, is not something like for Nix.

[b1ek]

in a different repo I think that is the case when the project will grrow

normally i would agree to move it later, but files urls in releases are something people will use in scripts, so its not very good to modify or remove them. so it has to be moved there right away.

why even have it in the compiler repo? i don't think there is a valid reason for having it here rather than in a separate one

[Ph0enixKM]

Debian packages are easy to use and not that hard to maintain. I see the reason to support just the most popular distributions so that we can maintain a good experience of the installation process.

[Ph0enixKM]

@Mte90 it seems that the CI still fails

[Ph0enixKM]

Tested and worked