CI: Build debian packages and run autopackage tests

[3v1n0]

Add a workflow to build debian packages and run autopkgtests.

UDENG-2343

[codecov-commenter]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 87.03%. Comparing base (d098b41) to head (dd5f794).
Report is 9 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #130      +/-   ##
==========================================
+ Coverage   86.87%   87.03%   +0.16%     
==========================================
  Files          64       64              
  Lines        4838     4891      +53     
==========================================
+ Hits         4203     4257      +54     
+ Misses        444      441       -3     
- Partials      191      193       +2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[didrocks]

There is a lot of assumptions on that PR, in particular in which distro to runs. Also, the containers in polluted with preparing the build package and end up having network connection when building it, which is not what a real ppa or builder is doing.

I think it will be better to reuse https://github.com/canonical/desktop-engineering/blob/main/gh-actions/common/build-debian/action.yml, amend it for anything needed without extending too much complexity. Please check with @EduardGomezEscandell who is the primary author.

Some of the changes that can be made for instance it to not rely on

    - name: Build package
      uses: jtdor/build-deb-action@v1

For instance, which should be easy enough to do.

That way, we can decide on which releases to build and ensure we have something closer to a real build environement. Adding autopkgtests as a separate action is interesting there too.

[didrocks]

This is an old way of instlaling build deps, let’s not create the dummy package are really on build-dep . funcitonality of apt.

[didrocks]

We don’t want to restrict on tags, everything that is push to main or opened as PR should have that passing.

[3v1n0]

There is a lot of assumptions on that PR, in particular in which distro to runs.

Consider this was done as a quick thing to test #120 (and actually caught few issues during the final testing of that PR :)).

So, there are assumptions but all depending on variables, so ideally can be multiplexed to multiple jobs, although this was not a requirement yet.

Also, the containers in polluted with preparing the build package and end up having network connection when building it, which is not what a real ppa or builder is doing.

Yeah, this has to be changed indeed.

I think it will be better to reuse https://github.com/canonical/desktop-engineering/blob/main/gh-actions/common/build-debian/action.yml, amend it for anything needed without extending too much complexity. Please check with @EduardGomezEscandell who is the primary author.

However I was looking at the code of that action and I'm not sure how internet is prevented there too, since it seems that certificates are still installed. However I'll dig on that more further.

[EduardGomezEscandell]

Hi, thanks for taking a look :)

However I was looking at the code of that action and I'm not sure how internet is prevented there too, since it seems that certificates are still installed. However I'll dig on that more further.

The action works in two phases, each in a separate container.

• The first one builds the source package, with certificates installed
• The second one builds the package, with no certificates.

[3v1n0]

• name: Build package
  uses: jtdor/build-deb-action@v1

Something I don't like of that is that it's running the build process as root, which is what other builders do, but it should not be the case. I can probably patch that to fix this though.

[3v1n0]

I've tried again using canonical/desktop-engineering/gh-actions/common/build-debian but still this doesn't work as per this error:

  dh_auto_configure --buildsystem=cargo
  debian cargo wrapper: options, profiles, parallel, lto: ['parallel=4'] ['noudeb'] ['-j4'] 0
  debian cargo wrapper: rust_type, gnu_type: x86_64-unknown-linux-gnu, x86_64-linux-gnu
  error: current package believes it's in a workspace when it's not:
  current:   /github/workspace/tmp.Vj6UHjMoxL/source/vendor_rust/tokio/Cargo.toml
  workspace: /github/workspace/Cargo.toml
  this may be fixable by adding `tmp.Vj6UHjMoxL/source/vendor_rust/tokio` to the `workspace.members` array of the manifest located at: /github/workspace/Cargo.toml
  Alternatively, to keep it out of the workspace, add the package to the `workspace.exclude` array, or add an empty `[workspace]` table to the package's manifest.
  malformed JSON string, neither array, object, number, string or atom, at character offset 0 (before "(end of string)") at /usr/share/cargo/bin/dh-cargo-vendored-sources line 23.
  dh_auto_configure: error: /usr/share/cargo/bin/dh-cargo-vendored-sources returned exit code 255
  make[1]: Leaving directory '/github/workspace/tmp.Vj6UHjMoxL/source'
  make[1]: *** [debian/rules:68: override_dh_auto_configure] Error 25
  make: *** [debian/rules:50: binary] Error 2
  dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2

It's quite weird since it does seems to run in the same environment.... And funny thing: there's no relevant difference in source packages as per debdiff.

So.... I'm not really sure what it is. I'll check in future, but I think that for now the safest way would just go with this option (once I address the comments on building based on the source and disabling internet access), instead of continuing living without a CI action that ensures we're still packaging authd properly.

[3v1n0]

Opening this again, even though now it's using canonical/desktop-engineering#28

[denisonbarbosa]

I'm not a big fan of having this running on every single PR and push to main, tbh. I think it's better to trigger this only if there were any changes on debian/, otherwise it will increase our CI time to run even more for little gain.

[3v1n0]

Eh... I would agree on that, if it wouldn't that test may fail in different conditions, and having it tested in a properly isolated testbed is the way.

I think also @didrocks agree'd as per #130 (comment).

However, one thing we could do is limit to changes on **/**_test.go file maybe?

[3v1n0]

Not sure if there's a way in github to run only a workflow when a PR is approved? As that would be a way to prevent problems to hit to main without having to test all the PR's from the very first moment.

[denisonbarbosa]

You can add a job that relies on the completion of another one by setting the needs: field, but I still think that this is not something we need to constantly watch for.

[denisonbarbosa]

Also, I'm afraid this kind of action might give users the wrong impression that the code in main is always "ready to use" when, in reality, this kind of project relies a lot on manual tests to ensure none of our dependencies regressed.

[3v1n0]

No, well that's not the point IMHO but at the same it's useful for testing having packages ready all the time.

But well, if someone think that, then is wrong as it would be wrong in any other project doing nightly builds.

However, I can see if can change this to reduce the scope of its action. I guess we'll do this after FF though since this still depends on canonical/desktop-engineering#28

[denisonbarbosa]

This is a CI related PR, so it can definitely wait and be done after FF.

[3v1n0]

Yeah, the reason for that was to get this early to be confident on uploading things working stuff to the distro, but we can still append these commits to temporary branches to check things for now.