build: ensure request hash is the same as build hash

[efahl]

When using 'packages_versions' the request hash that is calculated before request validation in 'api_v1_build_post' often differs from the one calculated in 'build'. This is due to 'validate_request' modifying the request's package lists.

We extract the request hash from the job, thus making them consistent again.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 91.36%. Comparing base (5e65dec) to head (8a28caf).
Report is 207 commits behind head on main.

Additional details and impacted files

@@             Coverage Diff             @@
##             main    #1188       +/-   ##
===========================================
+ Coverage   80.75%   91.36%   +10.61%     
===========================================
  Files          15       13        -2     
  Lines         977     1170      +193     
===========================================
+ Hits          789     1069      +280     
+ Misses        188      101       -87     

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

[aparcar]

Thanks, good point. Isn't something like below the "better" solution?

diff --git a/asu/util.py b/asu/util.py
index 0bf1b87..8704b74 100644
--- a/asu/util.py
+++ b/asu/util.py
@@ -141,7 +141,12 @@ def get_request_hash(build_request: BuildRequest) -> str:
                 build_request.version_code,
                 build_request.target,
                 build_request.profile.replace(",", "_"),
-                get_packages_hash(build_request.packages),
+                get_packages_hash(
+                    x.removeprefix("+")
+                    for x in (
+                        build_request.packages_versions.keys() or build_request.packages
+                    )
+                ),
                 get_manifest_hash(build_request.packages_versions),
                 str(build_request.diff_packages),
                 "",  # build_request.filesystem

[efahl]

Yeah, I like that (my first inclination was to do a least-intrusive patch).

What do you think about adding that to my current patch, rather than replacing it altogether? Then we get reproducible results, plus we save the time recomputing the hash...

[aparcar]

How are the results more reproducible? I think the computation of the hash is negligible, I don't know what the "get current job" function does in the background.

[efahl]

Reproducible in the sense that you can call get_request_hash before or after the validation step and you get the same result.

Looks like get_current_job is how we get job in the build function. The job parameter is completely ignored, never used by rq at all so we can get rid of it altogether.

I see no way of passing the actual job into build, since it's created after the call to enqueue and not included in the call (just the *args and **kwds are passed to the queued function, meaning we could actually pass the request hash in as an argument; I'll mangle this PR and you can take a look at it).

https://github.com/rq/rq/blob/master/rq/queue.py#L965
https://python-rq.org/docs/jobs/#job-creation