Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

validate dependencies after build #18

Open
v4hn opened this issue Mar 8, 2023 · 3 comments
Open

validate dependencies after build #18

v4hn opened this issue Mar 8, 2023 · 3 comments

Comments

@v4hn
Copy link
Owner

v4hn commented Mar 8, 2023

At the moment the action does not validate whether all exec dependencies are actually correctly mapped to the target system. So right now, e.g., jsk_tools builds successfully, but cannot be installed because pygithub3, slacker-cli, tabulate are no valid packages on Ubuntu 22.04.

The actual error here is that the rosdep keys/package.xml entries are inconsistent, which will be fixed soon. But this issue is about the action not reporting a failure in this case. I expect there is an easy way to check this around sbuild?

@jspricke
Copy link
Collaborator

jspricke commented Mar 9, 2023

At the moment the action does not validate whether all exec dependencies are actually correctly mapped to the target system. So right now, e.g., jsk_tools builds successfully, but cannot be installed because pygithub3, slacker-cli, tabulate are no valid packages on Ubuntu 22.04.

for completeness, the rosdep keys are python-pygithub3, python-slacker-cli and python-tabulate-pip and even for focal they are all resolved via pip. Consequently they are just missing from the OSRF Debian package, so a simple solution would be to define them as empty keys in the Action.

The actual error here is that the rosdep keys/package.xml entries are inconsistent, which will be fixed soon. But this issue is about the action not reporting a failure in this case. I expect there is an easy way to check this around sbuild?

In general Debian does not validate binary dependencies as they could come from any source. You could add something like:

SBUILD_CONF: |
  $external_commands = {
    "finished-build-commands" => [ [ 'apt-get', '-o=Debug::pkgProblemResolver=yes', '-y', 'install', './*.deb' ] ],
  };

Edit: There could also be cases where A build depends B but B run depends A so B could not be installable directly after the build.

@v4hn
Copy link
Owner Author

v4hn commented Oct 10, 2024

There could also be cases where A build depends B but B run depends A so B could not be installable directly after the build.

This was the main reason why I did not follow-up on the idea.

In lights of the current implementation, the staged build now bundles repositories where this is the case together as bonded, so this validation is possible for all packages in a worker after the worker finished.
But this also means that we cannot directly hijack the sbuild run, but need to run another independent step at the end (reusing the extra-repository, extra-package parameters for sbuild).

@jspricke
Copy link
Collaborator

Running it as an independent step is easy. You could use mmdebstrap for that like I do here:
https://github.com/defo-project/curl/blob/master/.github/workflows/packages.yaml#L64

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants