Add support for request context

[ogenstad]

Adds support for adding a request context to the SDK. This can be done at the root level of the client object or on individual requests. The idea here is that when running a generator we'd want to simplify this process for end users so that we add the context to the cloned SDK instance when running within the pipeline where as we wouldn't use this option when using infrahubctl.

Within the Infrahub pipeline we'd still need to be able to specify that specific objects should be saved using a context, such as when creating a validator or a check, then we are not able to set the context for the entire SDK instance.

There are still some calls missing (such as when creating branches etc) and tests would need to be written.

It would be used either like this:

from infrahub_sdk import InfrahubClient
from infrahub_sdk.context import RequestContext

context = RequestContext(account={"id": "182a86a2-05f0-37f8-58df-1746c80a346e"})

client = InfrahubClient()
client.request_context = context

data = {
    "name": "blue-tag",
}
obj = await client.create(kind="BuiltinTag", data=data)
await obj.save()

Alternatively like this:

from infrahub_sdk import InfrahubClient
from infrahub_sdk.context import RequestContext

context = RequestContext(account={"id": "182a86a2-05f0-37f8-58df-1746c80a346e"})

client = InfrahubClient()

data = {
    "name": "blue-tag",
}
obj = await client.create(kind="BuiltinTag", data=data)
await obj.save(request_context=context)

[codecov]

Codecov Report

Attention: Patch coverage is 52.17391% with 22 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
infrahub_sdk/node.py	56.25%	10 Missing and 4 partials ⚠️
infrahub_sdk/context.py	0.00%	6 Missing ⚠️
infrahub_sdk/client.py	85.71%	1 Missing ⚠️
infrahub_sdk/generator.py	0.00%	1 Missing ⚠️

@@                 Coverage Diff                  @@
##           infrahub-develop     #296      +/-   ##
====================================================
- Coverage             70.62%   70.50%   -0.13%     
====================================================
  Files                    85       86       +1     
  Lines                  7824     7852      +28     
  Branches               1513     1520       +7     
====================================================
+ Hits                   5526     5536      +10     
- Misses                 1908     1924      +16     
- Partials                390      392       +2     

Flag	Coverage Δ
integration-tests	21.66% <21.73%> (-0.02%)	⬇️
python-3.10	45.18% <21.73%> (-0.10%)	⬇️
python-3.11	45.18% <21.73%> (-0.13%)	⬇️
python-3.12	45.18% <21.73%> (-0.10%)	⬇️
python-3.13	45.21% <21.73%> (-0.10%)	⬇️
python-3.9	44.08% <21.73%> (-0.10%)	⬇️
python-filler-3.12	24.52% <28.26%> (-0.02%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
infrahub_sdk/client.py	67.53% <85.71%> (+0.14%)	⬆️
infrahub_sdk/generator.py	35.44% <0.00%> (-0.46%)	⬇️
infrahub_sdk/context.py	0.00% <0.00%> (ø)
infrahub_sdk/node.py	76.93% <56.25%> (-0.65%)	⬇️

... and 1 file with indirect coverage changes

🚀 New features to boost your workflow:

• ❄ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[dgarros]

With this implementation, will it be possible to define the context globally when we initialize the client ? I think this is important to support this option in addition to specifying a specific context for a specific request

[ogenstad]

With this implementation, will it be possible to define the context globally when we initialize the client ? I think this is important to support this option in addition to specifying a specific context for a specific request

If you check the first example in the description that's very close to this. The scenario I was picturing was specifically for use with the generators, where we'd want to set the context on a cloned client after it was cloned. The use case I'd see to have it directly on the initialize would be when we support running jobs within an isolated Docker container or pod, but perhaps you have some other use case that I'm missing?

[dgarros]

If you check the first example in the description that's very close to this. The scenario I was picturing was specifically for use with the generators, where we'd want to set the context on a cloned client after it was cloned. The use case I'd see to have it directly on the initialize would be when we support running jobs within an isolated Docker container or pod, but perhaps you have some other use case that I'm missing?

My bad I missed it, this is exactly what I had in mind too