Merge pull request #5814 from opsmill/jbr-resolve-conflits-merge-02212025

Resolve conflits merge 02212025

Author: wartraxx51

backend/tests/functional/branch/conftest.py

@@ -51,6 +51,26 @@ def car_person_branch_agnostic_schema() -> dict[str, Any]:
                     }
                 ],
             },
+            {
+                "name": "Roofrack",
+                "namespace": "Test",
+                "branch": BranchSupportType.AWARE.value,
+                "attributes": [
+                    {"name": "size", "kind": "Text", "unique": True},
+                ],
+                "relationships": [
+                    {
+                        "name": "car",
+                        "label": "Commander of Car",
+                        "peer": "TestCar",
+                        "optional": False,
+                        "kind": "Parent",
+                        "cardinality": "one",
+                        "direction": "outbound",
+                        "branch": BranchSupportType.AGNOSTIC.value,
+                    },
+                ],
+            },
         ],
     }
     return schema

backend/tests/functional/branch/test_delete_agnostic_rel.py

@@ -2,15 +2,58 @@
 
 from typing import TYPE_CHECKING, Any
 
+import pytest
+from infrahub_sdk.exceptions import GraphQLError
+
 from tests.helpers.test_app import TestInfrahubApp
 
 if TYPE_CHECKING:
     from infrahub_sdk import InfrahubClient
+    from infrahub_sdk.node import InfrahubNode
 
 
 class TestDeleteAgnosticRel(TestInfrahubApp):
+    @pytest.fixture(scope="class")
+    async def load_schema(self, client: InfrahubClient, car_person_branch_agnostic_schema: dict[str, Any]) -> None:
+        await client.schema.load([car_person_branch_agnostic_schema])
+
+    @pytest.fixture(scope="class")
+    async def owner_1(self, client: InfrahubClient, load_schema) -> InfrahubNode:
+        owner_1 = await client.create(kind="TestPerson", name="owner_1")
+        await owner_1.save()
+        return owner_1
+
+    @pytest.fixture(scope="class")
+    async def owner_2(self, client: InfrahubClient, load_schema) -> InfrahubNode:
+        owner_2 = await client.create(kind="TestPerson", name="owner_2")
+        await owner_2.save()
+        return owner_2
+
+    @pytest.fixture(scope="class")
+    async def car(self, client: InfrahubClient, load_schema, owner_1: InfrahubNode) -> InfrahubNode:
+        car = await client.create(kind="TestCar", name="car_name", owner=owner_1)
+        await car.save()
+        return car
+
+    @pytest.fixture(scope="class")
+    async def car_2(self, client: InfrahubClient, load_schema, owner_2: InfrahubNode) -> InfrahubNode:
+        car = await client.create(kind="TestCar", name="car_name_2", owner=owner_2)
+        await car.save()
+        return car
+
+    @pytest.fixture(scope="class")
+    async def roofrack_2(self, client: InfrahubClient, load_schema, car_2: InfrahubNode) -> InfrahubNode:
+        roofrack = await client.create(kind="TestRoofrack", size="big", car=car_2)
+        await roofrack.save()
+        return roofrack
+
     async def test_delete_agnostic_rel(
-        self, client: InfrahubClient, car_person_branch_agnostic_schema: dict[str, Any]
+        self,
+        client: InfrahubClient,
+        load_schema,
+        owner_1: InfrahubNode,
+        owner_2: InfrahubNode,
+        car: InfrahubNode,
     ) -> None:
         """
         Loads a car-person agnostic schema, then :
@@ -20,22 +63,42 @@ async def test_delete_agnostic_rel(
         This test makes sure changing owner, involving deleting relationship with first owner, works correctly.
         See https://github.com/opsmill/infrahub/issues/5559.
         """
+        car = await client.get(kind="TestCar", name__value="car_name", prefetch_relationships=True)
+        car.owner = owner_2
+        await car.save()
 
-        await client.schema.load([car_person_branch_agnostic_schema])
+        car = await client.get(kind="TestCar", name__value="car_name", prefetch_relationships=True)
+        assert car.owner.peer.name.value == "owner_2"
 
-        owner_1 = await client.create(kind="TestPerson", name="owner_1")
-        await owner_1.save()
+    async def test_delete_aware_mandatory_node_blocked(
+        self, client: InfrahubClient, owner_2: InfrahubNode, car: InfrahubNode
+    ) -> None:
+        owner_2 = await client.get(kind="TestPerson", name__value="owner_2")
 
-        car = await client.create(kind="TestCar", name="car_name", owner=owner_1)
-        await car.save()
+        with pytest.raises(GraphQLError) as exc:
+            await owner_2.delete()
+
+        assert (
+            f"Cannot delete TestPerson '{owner_2.id}'. It is linked to mandatory relationship owner on node TestCar '{car.id}'"
+            in exc.value.message
+        )
 
+    async def test_delete_agnostic_node(self, client: InfrahubClient, owner_2: InfrahubNode, car: InfrahubNode) -> None:
         car = await client.get(kind="TestCar", name__value="car_name", prefetch_relationships=True)
+        await car.delete()
 
-        owner_2 = await client.create(kind="TestPerson", name="owner_2")
-        await owner_2.save()
+        owner_2 = await client.get(kind="TestPerson", name__value=owner_2.name.value, prefetch_relationships=True)
+        assert len(owner_2.cars.peers) == 0
 
-        car.owner = owner_2
-        await car.save()
+    async def test_delete_aware_node_with_agnostic_parent_blocked(
+        self, client: InfrahubClient, car_2: InfrahubNode, roofrack_2: InfrahubNode
+    ) -> None:
+        car_2 = await client.get(kind="TestCar", name__value=car_2.name.value, prefetch_relationships=True)
 
-        car = await client.get(kind="TestCar", name__value="car_name", prefetch_relationships=True)
-        assert car.owner.peer.name.value == "owner_2"
+        with pytest.raises(GraphQLError) as exc:
+            await car_2.delete()
+
+        assert (
+            f"Cannot delete TestCar '{car_2.id}'. It is linked to mandatory relationship car on node TestRoofrack '{roofrack_2.id}'"
+            in exc.value.message
+        )

docker-compose.yml

@@ -207,7 +207,7 @@ services:
       retries: 5
 
   infrahub-server:
-    image: "${INFRAHUB_DOCKER_IMAGE:-registry.opsmill.io/opsmill/infrahub}:${VERSION:-1.1.7}"
+    image: "${INFRAHUB_DOCKER_IMAGE:-registry.opsmill.io/opsmill/infrahub}:${VERSION:-1.1.8a1}"
     restart: unless-stopped
     command: >
       gunicorn --config backend/infrahub/serve/gunicorn_config.py
@@ -253,7 +253,7 @@ services:
     deploy:
       mode: replicated
       replicas: 2
-    image: "${INFRAHUB_DOCKER_IMAGE:-registry.opsmill.io/opsmill/infrahub}:${VERSION:-1.1.7}"
+    image: "${INFRAHUB_DOCKER_IMAGE:-registry.opsmill.io/opsmill/infrahub}:${VERSION:-1.1.8a1}"
     command: prefect worker start --type infrahubasync --pool infrahub-worker --with-healthcheck
     restart: unless-stopped
     depends_on:

docs/docs/guides/artifact.mdx

@@ -8,15 +8,56 @@ import ReactPlayer from 'react-player/youtube'
 
 :::note
 
-This guide has the assumption that you followed the [Creating a Jinja Rendered File (Transform)](./jinja2-transform.mdx) or [Creating a Python transform](./python-transform.mdx) guide as well as [Creating a Group](./groups.mdx) guide
-This is a prerequisite.
+This guide has the assumption that you followed the [Creating a Jinja Rendered File (Transform)](./jinja2-transform.mdx) or [Creating a Python transform](./python-transform.mdx) guide. This is a prerequisite.
 
 :::
 
 The goal of this guide is to define an artifact for a Jinja rendered Transform or Python transform in Infrahub. We will be using the following steps.
 
-1. Creating an artifact definition
-2. Accessing the artifacts
+1. Modifying the schema
+2. Creating a group and adding member nodes
+2. Creating an artifact definition
+3. Accessing the artifacts
+
+## Modifying the node schema
+
+Before we can generate an artifact for a node, we need to modify the schema. The node will need to inherit from the `CoreArtifactTarget` generic.
+
+```yaml
+---
+version: "1.0"
+nodes:
+  - name: Device
+    namespace: Network
+    display_labels:
+      - name__value
+    inherit_from:
+      - CoreArtifactTarget
+    attributes:
+      - name: name
+        kind: Text
+        label: Name
+        optional: false
+        unique: true
+      - name: description
+        kind: Text
+        label: Description
+        optional: true
+```
+
+We then have to load the modified schema definition into Infrahub.
+
+```bash
+infrahubctl schema load /tmp/schema.yml
+```
+
+## Creating a group and adding members
+
+We need to create a group for every Artifact Definition that we will define. An artifact will be generated for every member that is part of that group.
+
+Create a Standard Group with the name `DeviceGroup` and add `NetworkDevice` `switch1`, `switch2` and `switch3` as a member.
+
+More information can be found in the [Creating a group guide](./groups.mdx).
 
 <center>
   <ReactPlayer url='https://www.youtube.com/watch?v=ASGMKZVLCbY' light />
@@ -26,23 +67,23 @@ The goal of this guide is to define an artifact for a Jinja rendered Transform o
 
 In the last step we need to define an Artifact definition, which groups together a [transformation](../topics/transformation.mdx) with a target group and forms the definition of the artifact. Artifact definitions can be created via the frontend, via GraphQL or via a [Git repository](../topics/repository.mdx). In this guide we will be using the Git repository.
 
-Add the following contents to the end of the `.infrahub.yml` file at the root of the `tags_render` repository.
+Add the following contents to the end of the `.infrahub.yml` file at the root of the `device_config_render` repository.
 
 ```yaml
 artifact_definitions:
-  - name: "tags_config_file"
-    artifact_name: "Tags configuration file"
+  - name: "device_configuration"
+    artifact_name: "Device configuration file"
     parameters:
-      tag: "name__value"
+      name: "name__value"
     content_type: "text/plain"
-    targets: "TagConfigGroup"
-    transformation: "my-transform"
+    targets: "DeviceGroup"
+    transformation: "device_config_transform"
 ```
 
 This defines an artifact with the following properties:
 
 - **name**: a unique name for the artifact
-- **parameters**: the parameter to pass to the transformation GraphQL query, in this case this we will pass the name of the object (tag) as the tag parameter
+- **parameters**: the parameter to pass to the transformation GraphQL query, in this case this we will pass the name of the object (device) as the name parameter
 - **content type**: the content type for the resulting artifact
 - **targets**: the name of a group of which the members will be a target for this artifact
 - **transformation**: the Jinja2 or Python transformation that should be used
@@ -53,11 +94,11 @@ Commit the changes to the repository and push them to the Git server
 
 ```shell
 git add .
-git commit -m "add tags_config_file artifact definition"
+git commit -m "add device_configuration artifact definition"
 git push origin main
 ```
 
-The artifact definition will be created in the database, when the Task worker(s) notice the change in the Git repository. The `tags_config_file` should now be visible in the Artifact Definition view in the web interface.
+The artifact definition will be created in the database, when the Task worker(s) notice the change in the Git repository. The `device_configuration` should now be visible in the Artifact Definition view in the web interface.
 ![Artifact Definition](../media/guides/artifact/artifact_definition.png)
 
 ## Accessing the artifacts
@@ -69,6 +110,8 @@ The artifacts are generated by the git-agents. You can find the resulting artifa
 Open an artifact to get the result.
 
 ![Artifact detail](../media/guides/artifact/artifact_detail.png)
-You can download the artifact by clicking on the `Storage Id` or alternatively through the rest API endpoint `http://<INFRAHUB_HOST:INFRAHUB_PORT>/api/storage/object/<storage_id>`
+You can download the artifact by clicking on the download button, or by using the REST API endpoint `http://<INFRAHUB_HOST:INFRAHUB_PORT>/api/storage/object/<storage_id>`. The `Storage Id` can be copied from the menu next to the artifact name.
+
+![Artifact menu](../media/guides/artifact/artifact_menu.png)
 
-Optionally, Infrahub can create a relation between a node and an artifact, by inheriting from the CoreArtifactTarget generic in the schema of the node. This is outside the scope of this guide, since the BuiltinTag node does not inherit from CoreArtifactTarget. More information can be found in the [artifact](../topics/artifact.mdx) topic.
+Alternatively we can access the artifact of an object, by navigating to the object detail view. Navigate to device `switch1`'s detail page, from the *Artifacts* tab you can access all the artifacts that were generated for this object.

docs/docs/guides/check.mdx

@@ -110,7 +110,7 @@ Then save the `TagsQuery` as a text file named `tags_check.gql`.
 
 ### 2. Create the Python check file
 
-The next step is to create the Check Python business logic. The check is a Python class that inherits from `InfrahubCheck` from the [Python SDK](../python-sdk). Create a file called `tags_check.py`:
+The next step is to create the Check Python business logic. The check is a Python class that inherits from `InfrahubCheck` from the [Python SDK]($(local_base_url_1)python-sdk). Create a file called `tags_check.py`:
 
 ```python
 import re

docs/docs/guides/generator.mdx

@@ -104,7 +104,7 @@ We provide `convert_query_response` option to be toggled to be able to access ob
 
 This allows you to manage the returned data with helper methods on the SDK objects such as `save`, `fetch`, etc. on the returned data rather than having to build a payload to send back to Infrahub to manage the objects.
 
-Read more on the [Infrahub Python SDK](../python-sdk).
+Read more on the [Infrahub Python SDK]($(local_base_url_1)python-sdk).
 :::
 
 <Tabs groupId="convertResponse">
@@ -291,7 +291,7 @@ widget_generator (widget_generator.py::Generator) Target: widgets
 
 :::warning
 
-When running a generator with `infrahubctl` the [SDK tracking](../python-sdk/topics/tracking) feature isn't used. The reason for this is that internally Infrahub uses the ID of the generator_definition to control the tracking, this isn't available from the outside. For this reason it is recommended to create test branches when developing generators and validating the results.
+When running a generator with `infrahubctl` the [SDK tracking]($(local_base_url_1)python-sdk/topics/tracking) feature isn't used. The reason for this is that internally Infrahub uses the ID of the generator_definition to control the tracking, this isn't available from the outside. For this reason it is recommended to create test branches when developing generators and validating the results.
 
 :::