feat(gh-actions/build-debian): Support running a workflow script at build-source phase

[3v1n0]

When building some packages we may need to prepare the build environment before preparing the source package, for example in some cases we may need to enable git access (to compute the package version or similar) or we may need to install tools that are used during debian source building that are not provided in the archive (such as rust crates, hello cargo-vendor-filterer!!).

So instead of polluting this generic action with package-specific requirements, let's just make it support running a script that can do more advanced configurations in the docker instance that is used only during the source-preparation phase.

Not covering the migration yet (since I'd like to provide some more tools for it), but I think that we should drop the specific-git code from this action too, and move it where it's relevant (in the ubuntu-pro-for-wsl repo as action input script instead).

This is required in order to be able to do a cargo install --root=/usr cargo-vendor-filterer to build the source package of rust programs as required by authd in ubuntu/authd#130

UDENG-2343

[adombeck]

Alternatively to specifying a new input, we could also always check if a script /usr/bin/pre-build-hook (or something like that) exists and execute it if it does.

[3v1n0]

Alternatively to specifying a new input, we could also always check if a script /usr/bin/pre-build-hook (or something like that) exists and execute it if it does.

The problem of that is that it would imply saving something in a place (the docker instance) that the workflow has no access to, so that's something we can't do easily. Indeed we could allow the input to be a file instead that can be copied there though.

But I feel this syntax still allows to keep everything in the same place (the calling workflow file) easily. Indeed we could support injecting another file in future though.

[adombeck]

The problem of that is that it would imply saving something in a place (the docker instance) that the workflow has no access to, so that's something we can't do easily.

Ah, so you intend to provide the script via the git repo, not via the Docker image? Then we could also check ${{ github.workspace }}/bin/pre-build-hook or something.

But I feel this syntax still allows to keep everything in the same place (the calling workflow file) easily. Indeed we could support injecting another file in future though.

Works for me.

[3v1n0]

Ah, so you intend to provide the script via the git repo, not via the Docker image? Then we could also check ${{ github.workspace }}/bin/pre-build-hook

yeah... Ideally such path should be provided, but with this way it's still possible to just launch it manually with one line, since the workspace is always already mounted... So I'd keep this way still.

If something more complex is needed, we can reiterate :)

[3v1n0]

This has been tested working in the only customer (so far) so let's merge it. :)