You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the new packaging convention, every build job is bound to a system architecture. For example, build.x86_64-linux, builds a particular package for x86-64-linux.
However, using this new convention makes it difficult (or I would say: almost impossible) for a jobset to refer to an existing build result for the same architecture belonging to a different jobset.
In the old convention, I could directly address an existing build result through. project:jobset:job and pick the 'Build result (same system)' to use a build result from another jobset.
Although Hydra still supports this old feature, it can no longer be used with a release expression following the new convention.
I know two possible solutions. One solution is to allow a release expression to refer to a jobset result, e.g. through an attribute set referring to builtins.storePath invocations.
Another solutions is to adapt the 'Build result (same system)' option to use the new convention (e.g. by automatically referring to the desired system architecture sub attribute).
The text was updated successfully, but these errors were encountered:
In the new packaging convention, every build job is bound to a system architecture. For example,
build.x86_64-linux
, builds a particular package for x86-64-linux.However, using this new convention makes it difficult (or I would say: almost impossible) for a jobset to refer to an existing build result for the same architecture belonging to a different jobset.
In the old convention, I could directly address an existing build result through. project:jobset:job and pick the 'Build result (same system)' to use a build result from another jobset.
Although Hydra still supports this old feature, it can no longer be used with a release expression following the new convention.
I know two possible solutions. One solution is to allow a release expression to refer to a jobset result, e.g. through an attribute set referring to builtins.storePath invocations.
Another solutions is to adapt the 'Build result (same system)' option to use the new convention (e.g. by automatically referring to the desired system architecture sub attribute).
The text was updated successfully, but these errors were encountered: