CI: Build debian packages and run autopackage tests

[3v1n0]

Add a workflow to build debian packages and run autopkgtests.

Requires: canonical/desktop-engineering#58

UDENG-2343

[codecov-commenter]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 83.18%. Comparing base (36511cd) to head (dee7b3a).
Report is 73 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #130      +/-   ##
==========================================
- Coverage   83.43%   83.18%   -0.26%     
==========================================
  Files          83       87       +4     
  Lines        8689     8771      +82     
  Branches       74       74              
==========================================
+ Hits         7250     7296      +46     
- Misses       1111     1143      +32     
- Partials      328      332       +4     

☔ 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.

[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

It was based on the old code, and comments have been addressed.

[denisonbarbosa]

Thanks for handling this!