Fix accessing nodes (check, generate) from objects

[eunomie]

Note

This is a follow up to #11827 that was (partially) solving #11811

Problem | State

check and generate functions must be listed and callable.

When check and generate functions are defined on the main object of a module, it's working.

#11827 was solving the case where check and generate functions are defined on a different object of a module. But this was working only on the "main" dagger module and not when defined in toolchain modules.

Fix

The core change is to replace node.Module.Toolchains.Get(name) by node.Module.Toolchains.GetByFieldName(name) to access to the right module defining the object returned by a function. In case of a toolchain, the toolchain's object is returned by the root module, that is different than the toolchain's module. This toolchain's module is required to get access to the right type.

Example:

Let's say we have a root module, defining a toolchain python-sdk. This toolchain has a function tests returning an object PythonTests that contains two check functions called slow and unit.
When we will walk the dag of functions:

• on the root module, we'll see a function pythonSdk that returns a PythonSdk type (the toolchain)
  • at this point rootNode.Module.Toolchains.Get("pythonSdk") will return the PythonSdk toolchain module
  • ObjectByName on this module will allow to return the right pythonSdk type that can be explored
• when walking PythonSdk type, there's a tests function returning an object of type PythonSdkPythonTests (because of nesting namespace)
  • to inspect this type, we need again to call ObjectByName on the PythonSdk module and not the root module one
• by walking PythonSdkPythonTests, we can see the two check functions slow and unit

Previously, the way we access the "original module" was wrong. It was working outside of a toolchain because there's only one module, so it didn't matter. This fix ensures the right module is returned and so the types are correctly inspected.

This also includes a small fix to ensure we are not duplicating the nodes, one from the root module, one from the toolchain module.

The TestChecksAsToolchain has been extended to ensure we can read check functions from object from toolchain.

Real use case

As a real world example, this allows for instance to explode a test matrix in objects and functions.

Note

This will be available in a follow up PR but sharing it here to show, outside of the bug fix, the possibilities

Previously:

$ dagger check -l

...
python-sdk:test                       Test the Python SDK
...

This check function will run, in parallel, the same test functions on multiple python versions. That's great but it means if we only need to run the tests on a single version (for quick feedback), it's not available by default. Or hidden behind an argument meaning we need to move away from dagger check to dagger call with arguments.

$ dagger check-l

...
python-sdk:python-310:slow            Run slow python tests
python-sdk:python-310:unit            Run unit tests.
python-sdk:python-311:slow            Run slow python tests
python-sdk:python-311:unit            Run unit tests.
python-sdk:python-312:slow            Run slow python tests
python-sdk:python-312:unit            Run unit tests.
python-sdk:python-313:slow            Run slow python tests
python-sdk:python-313:unit            Run unit tests.
python-sdk:python-314:slow            Run slow python tests
python-sdk:python-314:unit            Run unit tests.
...

In that case, all the specific test functions are exposed. A specific one can be called (dagger check "python-sdk:python-314:unit"), or all unit test functions at once (dagger check "python-sdk:**:unit"), or all test functions for a specific python (dagger check "python-sdk:python-312"). This brings more clarity and possibilities for the user while still having the same final result (meaning all tests are run)