Add development chain-spec file for minimal/parachain templates for Omni Node compatibility #6529

EleisonC · 2024-11-18T18:45:05Z

Description

This PR adds development chain specs for the minimal and parachain templates. #6334

Integration

This PR adds development chain specs for the minimal and para chain template runtimes, ensuring synchronization with runtime code. It updates zombienet-omni-node.toml, zombinet.toml files to include valid chain spec paths, simplifying configuration for zombienet in the parachain and minimal template.

Review Notes

Overview of Changes:

Added development chain specs for use in the minimal and parachain template.
Updated zombienet-omni-node.toml and zombinet.toml files in the minimal and parachain templates to include paths to the new dev chain specs.

Integration Guidance:
NB: Follow the templates' READMEs from the polkadot-SDK master branch. Please build the binaries and runtimes based on the polkadot-SDK master branch.

Ensure you have set up your runtimes parachain-template-runtime and minimal-template-runtime
Ensure you have installed the nodes required ie parachain-template-node and minimal-template-node
Set up Zombinet
For running the parachains, you will need to install the polkadot cargo install --path polkadot remember from the polkadot-SDK master branch.
Inside the template folders minimal or parachain, run the command to start with Zombienet with Omni Node, Zombienet with minimal-template-node or Zombienet with parachain-template-node

Include your leftover TODOs, if any, here.

Test the syncing of chain specs with runtime's code.

cla-bot-2021 · 2024-11-18T18:45:12Z

User @EleisonC, please sign the CLA here.

…adot-sdk into add-dev-chain-spec

This reverts commit 80669c1.

iulianbarbu

Thanks @EleisonC ! Left a few comments for now.
Looking forward to the README updates & btw, have you clarified how to make a rust test for the chain specs?

templates/minimal/zombienet.toml

templates/parachain/zombienet.toml

EleisonC · 2024-11-20T13:55:29Z

Thanks @EleisonC ! Left a few comments for now. Looking forward to the README updates & btw, have you clarified how to make a rust test for the chain specs?

Hey @iulianbarbu that is what I am looking into today. Do you have any pointers you'd like me to know as I move forward?

iulianbarbu · 2024-11-20T14:06:34Z

Thanks @EleisonC ! Left a few comments for now. Looking forward to the README updates & btw, have you clarified how to make a rust test for the chain specs?

Hey @iulianbarbu that is what I am looking into today. Do you have any pointers you'd like me to know as I move forward?

From the top of my head I thought about adding an integration test. You could build a ChainSpec as described here: https://github.com/paritytech/polkadot-sdk/blob/master/templates/parachain/node/src/chain_spec.rs#L36, and then call as_json -> and then convert it to serde_json::Value, and then read the newly added file and load its content as a serde_json::Value and then compare the two.

EleisonC · 2024-11-21T06:10:50Z

Hey @iulianbarbu one last question it's okay if I placed the test folder/file under the nodes folder/file. if not is there a better place

iulianbarbu · 2024-11-21T09:37:35Z

Hey @iulianbarbu one last question it's okay if I placed the test folder/file under the nodes folder/file. if not is there a better place

Hmm, thought about placing it under runtime initially. I think it makes more sense to place it under runtime so that if anything changes here, running the tests for the crate would fail because the changes will not be inline with dev_chain_spec.json. The node uses the logic defined in the runtime, so it would benefit from the runtime test, but not directly. I don't think we need to add a test on the same lines in the templates' nodes crate either because these nodes aren't depending on the dev_chain_spec.json file. Only OmniNode depends on this file being in sync with the runtime, and that not because it would fail otherwise, but because it would start an outdated version.

EleisonC · 2024-11-25T14:19:51Z

From the top of my head I thought about adding an integration test. You could build a ChainSpec as described here: https://github.com/paritytech/polkadot-sdk/blob/master/templates/parachain/node/src/chain_spec.rs#L36, and then call as_json -> and then convert it to serde_json::Value, and then read the newly added file and load its content as a serde_json::Value and then compare the two.

Hey @iulianbarbu regarding comparing the two I am a bit stuck on what to compare. From my research I would think it's other the code or value of top
Is it the value of code? Because the test fails when I compare the code value of the two chain spec files.
let test_runtime_code = test_json_value // .get("genesis") // .expect("failed to extract genesis") // .get("runtimeGenesis") // .expect("failed to extract runtimeGenesis from genesis") // .get("code") // .expect("failed to extract code from runtimeGenesis");
But the code value of test_runtime and the existing file do not match. Hence wondering if it would be the Top value to or maybe I am missing a step of conversion somewhere

EleisonC · 2024-11-26T02:54:35Z

From the top of my head I thought about adding an integration test. You could build a ChainSpec as described here: https://github.com/paritytech/polkadot-sdk/blob/master/templates/parachain/node/src/chain_spec.rs#L36, and then call as_json -> and then convert it to serde_json::Value, and then read the newly added file and load its content as a serde_json::Value and then compare the two.

Hey @iulianbarbu regarding comparing the two I am a bit stuck on what to compare. From my research I would think it's other the code or value of top Is it the value of code? Because the test fails when I compare the code value of the two chain spec files. let test_runtime_code = test_json_value // .get("genesis") // .expect("failed to extract genesis") // .get("runtimeGenesis") // .expect("failed to extract runtimeGenesis from genesis") // .get("code") // .expect("failed to extract code from runtimeGenesis"); But the code value of test_runtime and the existing file do not match. Hence wondering if it would be the Top value to or maybe I am missing a step of conversion somewhere

I figured out my problem was around decoding a Hex String to bytes. I can now properly traverse the values of the Top section and find the code for that spec file

iulianbarbu · 2024-11-27T12:45:36Z

From the top of my head I thought about adding an integration test. You could build a ChainSpec as described here: https://github.com/paritytech/polkadot-sdk/blob/master/templates/parachain/node/src/chain_spec.rs#L36, and then call as_json -> and then convert it to serde_json::Value, and then read the newly added file an

d load its content as a serde_json::Value and then compare the two.

Hey @iulianbarbu regarding comparing the two I am a bit stuck on what to compare. From my research I would think it's other the code or value of top Is it the value of code? Because the test fails when I compare the code value of the two chain spec files. let test_runtime_code = test_json_value // .get("genesis") // .expect("failed to extract genesis") // .get("runtimeGenesis") // .expect("failed to extract runtimeGenesis from genesis") // .get("code") // .expect("failed to extract code from runtimeGenesis"); But the code value of test_runtime and the existing file do not match. Hence wondering if it would be the Top value to or maybe I am missing a step of conversion somewhere

I figured out my problem was around decoding a Hex String to bytes. I can now properly traverse the values of the Top section and find the code for that spec file

Happy to hear you've sorted it out! I've noticed that in some tests we don't compare the code portions of the generated chain specs, and that's mainly because they are not super relevant for the test case. For this test though I think that it is relevant, to ensure generated chain specs correspond to the runtimes in the CI.

Some other good news is that once we'll have these chain specs we'll be able to easily run in the CI the omni_node_* tests like this one: https://github.com/paritytech/polkadot-sdk/blob/master/templates/zombienet/tests/smoke.rs#L160. We can update them in a follow up, no need to consider them right now, but it is up to you.

As usual, LMK in case of blockers, happy to take a look.

Signed-off-by: EleisonC <[email protected]>

EleisonC · 2024-11-27T22:47:09Z

Hey @iulianbarbu,
I added a test and would appreciate it if you could look at it and approve it before I add the one for the para chain. Additionally, I added the test folder to nodes because I was encountering setup issues.

iulianbarbu

Can you please regenerate the dev_chain_spec.json for minimal (for now) after building the minimal/runtime with cargo build? I wonder if you built the runtime with --release and then generated the dev_chain_spec.json. It makes sense according to the README, but we run the tests with the testnet profile, which enables the debug symbols, and I think the chain spec code section differs based on the profile. I would be curious to run the test again after you regenerate the dev_chain_spec.json, and also see if regenerating on my machine results in a different code section, or chain spec altogheter.

templates/minimal/node/tests/validate_dev_chain_spec.rs

templates/minimal/node/Cargo.toml

iulianbarbu · 2025-01-06T08:53:09Z

Hey @EleisonC ! First of all, sorry for my silence, it has been the end of the year and I took some needed time off.

Second of all, I have to admit I totally missed the aspect of this CI job failing at every minor change done in polkadot-sdk, in any crate which is a dependency of any of the two runtimes (minimal or parachain). At this point I am leaning towards @skunert idea of dropping the CI job, considering it will bring attention with most PRs and its benefit - ensuring the chain specs that come with the templates are up to date for usage of templates based on polkadot-sdk repo, when we aim in fact for usage from their dedicated GH repos (e.g. https://github.com/paritytech/polkadot-sdk-parachain-template).

Generating the chain specs once in this job: https://github.com/paritytech/polkadot-sdk/blob/master/.github/workflows/misc-sync-templates.yml should be enough IMO, from the point of view of ensuring up to date chain specs (in relation to the code found in their repo), and ease the use when it comes to OmniNode. LMK if you think differently.
I also believe the CI job effort can conclude nicely in this script you're proposing, which can be used anytime we want to update the chain specs for polkadot-sdk (as a nice to have, we can also print some notes right before the script is doing its thing, about the merging of master with the branch for the case of a PR, in case we want to update the chain spec as it would be done in CI), or when we generate the chain specs in the misc-sync-templates action. This script can install srtool if not present and check the environment looks fine (having at least podman installed). The script can be added as a follow up though (but it is your choice, given the misc-sync-templates.yml would contain similar commands, and could very well use a script that can do the same separately from the action).

Lastly, wanted to say that your work here was a great learning experience for me too. Would be happy to assist and review any followup changes if you can invest some more time here. LMK your thoughts.

EleisonC · 2025-01-06T17:25:14Z

Hey @EleisonC ! First of all, sorry for my silence, it has been the end of the year and I took some needed time off.

Hey @iulianbarbu I agree the time-off it is needed. I did the same. It was Christmas I bet it was enough haha. Information overload can happen quickly. 😅

Second of all, I have to admit I totally missed the aspect of this CI job failing at every minor change done in polkadot-sdk, in any crate which is a dependency of any of the two runtimes (minimal or parachain). At this point I am leaning towards @skunert idea of dropping the CI job, considering it will bring attention with most PRs and its benefit - ensuring the chain specs that come with the templates are up to date for usage of templates based on polkadot-sdk repo, when we aim in fact for usage from their dedicated GH repos (e.g. https://github.com/paritytech/polkadot-sdk-parachain-template).

Generating the chain specs once in this job: https://github.com/paritytech/polkadot-sdk/blob/master/.github/workflows/misc-sync-templates.yml should be enough IMO, from the point of view of ensuring up to date chain specs (in relation to the code found in their repo), and ease the use when it comes to OmniNode. LMK if you think differently.

Based on this my Next steps are going to be to :

- Remove the current CI job that verifies chain specs
- Add chain spec generation to the misc-sync-templates.yml workflow
- Generate specs only during template synchronization
- Update the ReadMe

I also believe the CI job effort can conclude nicely in this script you're proposing, which can be used anytime we want to update the chain specs for polkadot-sdk (as a nice to have, we can also print some notes right before the script is doing its thing, about the merging of master with the branch for the case of a PR, in case we want to update the chain spec as it would be done in CI), or when we generate the chain specs in the misc-sync-templates action. This script can install srtool if not present and check the environment looks fine (having at least podman installed). The script can be added as a follow up though (but it is your choice, given the misc-sync-templates.yml would contain similar commands, and could very well use a script that can do the same separately from the action).

This can be done in another PR. Its still hints at one of the earlier solutions
Create a utility script that:
Installs srtool if not present
Verifies at least podman installation
Generates chain specs on demand
Prints informative notes about branch merging
Can be used both manually and by the sync workflow

Lastly, wanted to say that your work here was a great learning experience for me too. Would be happy to assist and review any followup changes if you can invest some more time here. LMK your thoughts.

This is work I am proud of and definitely committed to seeing through. Also, I appreciate your continued guidance and support it makes the process easier.

EleisonC · 2025-01-16T21:54:12Z

Hey @iulianbarbu, I’d love to hear your thoughts on my approach and whether it aligns with the expectations.
cc: @skunert – I would appreciate your perspective as well.

iulianbarbu

Hi @EleisonC ! This is very nice and looks about done, except a few things that can be improved.

I plan to sync the templates with stable2412 release today & hopefully this will work without significant issues. Once that's done you can read every template readme as if it would be part of the dedicated template repos. This is just as FYI, I don't think you need to change more than what I suggested with this review, for this PR.

Other than this, would be great to open an issue related to the script we've discussed about, where we'll apply all this learnings about how to generate reproducible chain specs, if needed.

.github/workflows/misc-sync-templates.yml

templates/minimal/README.md

templates/parachain/README.md

iulianbarbu · 2025-01-17T13:10:29Z

Other than this I plan to sync the templates with stable2412 release today & hopefully this will work without significant issues.

Can't be done yet. Sync job is still failing because it tries to update the templates' repos Cargo.toml deps versions based on the stable2412 tag, which doesn't have a commited Plan.toml (it was added after the tag was made). We'll need to wait for the stable2412-1 planned for next week, its tag, and then try to sync again.

skunert

Looking really good, only minor nits!

Thanks again for seeing this through :)!

.github/workflows/misc-sync-templates.yml

templates/minimal/README.md

Co-authored-by: Iulian Barbu <[email protected]>

no need

EleisonC · 2025-01-18T22:50:43Z

Looking really good, only minor nits!

Thanks again for seeing this through :)!

Thank you for your guidance and feedback! I've addressed the minor nits. 😊

skunert

Looking good to me now! @iulianbarbu please verify the introduced workflow once more when you are back, then we are ready to go!

skunert · 2025-01-21T08:40:28Z

.github/workflows/misc-sync-templates.yml

+        - name: Prepare upload directory
+          run: |
+            mkdir -p artifacts-${{ matrix.template }}
+            cp dev_chain_spec.json artifacts-${{ matrix.package_name }}/dev_chain_spec.json


Here you are using matrix.package_name instead of matrix.template, I think this is a mismatch.

Thanks for the catch. I have addressed it

iulianbarbu

Just felt we can make the docs a bit clearer, so left a few clarifying comments, besides a few others for the misc-sync-templates.yml. It is mostly there :D

iulianbarbu · 2025-01-22T08:10:11Z

.github/workflows/misc-sync-templates.yml

+      - uses: actions/checkout@v4
+        with:
+          path: polkadot-sdk
+          ref: "${{ github.event.inputs.stable_release_branch }}"
+
+      - name: Download template artifacts
+        uses: actions/download-artifact@v4
+        with:
+          name: artifacts-${{ matrix.template }}
+          path: templates/${{ matrix.template }}/
+        if: matrix.template != 'solochain'


Can we remove the first action checkout here? We're doing it once more below, after setting the git identity. I am thinking we can also move the Download template artifacts below the actions checkout that runs after Configure git identity. What do you think?

iulianbarbu · 2025-01-22T08:11:47Z

templates/minimal/README.md

 - 👤 The template has no consensus configured - it is best for experimenting with a single node network.

+
+- For the most up-to-date chain specification, refer to [staging-chain-spec-builder](https://crates.io/crates/staging-chain-spec-builder)


I would remove this note from the intro. It isn't very relevant from an introduction standpoint for the template, and the latest info for the chain spec isn't necessarily part of staging-chain-spec-builder. I would keep the #Intro section as before.

You don't need to add a mention about staging-chain-spec-builder in other place either. We already have it mentioned in the steps below (e.g. under Starting a Minimal Template Chain/Omni Node/Install staging-chain-spec-builder.

iulianbarbu · 2025-01-22T08:17:36Z

templates/minimal/README.md

+To simplify the process of starting the minimal template with zombienet and Omni Node, we've added a pre-configured 
+development chain spec (dev_chain_spec.json) to the minimal template. The zombienet-omni-node.toml file of this template
+points to it, but you can update it to an updated path to the new chain spec generated on your machine, as shown below.


Suggested change

To simplify the process of starting the minimal template with zombienet and Omni Node, we've added a pre-configured

development chain spec (dev_chain_spec.json) to the minimal template. The zombienet-omni-node.toml file of this template

points to it, but you can update it to an updated path to the new chain spec generated on your machine, as shown below.

To simplify the process of starting the minimal template with zombienet and Omni Node, we've added a pre-configured

development chain spec (dev_chain_spec.json) to the minimal template. The zombienet-omni-node.toml file of this template

points to it, but you can update it to an updated path to the new chain spec generated on your machine.

My initial suggestion was to move this right into the section: Update zombienet-omni-node.toml with a valid chain spec path. It can be placed right at the beginning of the section, but then I would change the next paragraph: Before starting... by removing the first sentence.

iulianbarbu · 2025-01-22T08:26:37Z

templates/parachain/README.md

+
+To simplify the process of using the parachain-template with zombienet and Omni Node, we've added a pre-configured
+development chain spec (dev_chain_spec.json) to the parachain template. The zombienet-omni-node.toml file of this
+template points to it, but you can update it to an updated chain spec generated on your machine, as shown below:


Exactly the same as for minimal

iulianbarbu · 2025-01-22T08:29:20Z

.github/workflows/misc-sync-templates.yml

+          - template: parachain
+            package_name: 'parachain-template-runtime'
+            runtime_path: './templates/parachain/runtime'
+            runtime_wasm_path: 'minimal-template-runtime/minimal_template_runtime.compact.compressed.wasm'


Suggested change

runtime_wasm_path: 'minimal-template-runtime/minimal_template_runtime.compact.compressed.wasm'

runtime_wasm_path: 'parachain-template-runtime/parachain_template_runtime.compact.compressed.wasm'

EleisonC added 5 commits November 16, 2024 23:26

Add development chain spec config

3743b9f

Add path chain_spec_path

1e833b4

Add path chain_spec_path

3345130

Add development chain spec for parachain template

97a1cc2

Update chain spec path

80669c1

EleisonC and others added 5 commits November 18, 2024 21:56

Merge branch 'master' into add-dev-chain-spec

7a060c5

Merge branch 'add-dev-chain-spec' of https://github.com/EleisonC/polk…

91e0ba8

…adot-sdk into add-dev-chain-spec

Revert "Update chain spec path"

d97247d

This reverts commit 80669c1.

update chain_spec_path

301ab59

Merge branch 'master' into add-dev-chain-spec

541b524

iulianbarbu self-requested a review November 19, 2024 15:03

iulianbarbu added T17-Templates This PR/Issue is related to templates T11-documentation This PR/Issue is related to documentation. labels Nov 19, 2024

iulianbarbu assigned EleisonC Nov 19, 2024

iulianbarbu added the R0-silent Changes should not be mentioned in any release notes label Nov 19, 2024

iulianbarbu reviewed Nov 20, 2024

View reviewed changes

templates/minimal/zombienet.toml Outdated Show resolved Hide resolved

templates/parachain/zombienet.toml Outdated Show resolved Hide resolved

EleisonC and others added 2 commits November 21, 2024 05:40

Merge branch 'master' into add-dev-chain-spec

02e431e

remove chain spec path not required

0146534

EleisonC and others added 2 commits November 28, 2024 01:32

Add runtime test for minimal dev chain spec

14a32f1

Signed-off-by: EleisonC <[email protected]>

Merge branch 'master' into add-dev-chain-spec

2c318e3

iulianbarbu reviewed Nov 28, 2024

View reviewed changes

EleisonC and others added 8 commits January 6, 2025 20:25

Merge branch 'master' into add-dev-chain-spec

eb4c8aa

Merge branch 'master' into add-dev-chain-spec

da09ab4

intergrate chain spec creation into sync templates workflow

e21561e

remove chain spec verification workflow

6a01d91

Merge branch 'master' into add-dev-chain-spec

d30ac61

update minimal readme

76a55d2

update parachain readme

1330a45

Merge branch 'master' into add-dev-chain-spec

503477d

iulianbarbu reviewed Jan 17, 2025

View reviewed changes

skunert reviewed Jan 17, 2025

View reviewed changes

.github/workflows/misc-sync-templates.yml Outdated Show resolved Hide resolved

templates/minimal/README.md Outdated Show resolved Hide resolved

EleisonC and others added 6 commits January 18, 2025 03:17

Update .github/workflows/misc-sync-templates.yml

fad8110

Co-authored-by: Iulian Barbu <[email protected]>

Update templates/minimal/README.md

3748999

Co-authored-by: Iulian Barbu <[email protected]>

changes

7c2988c

changes parachain readme

f6da52d

add --locked for consistent deps

e2bd3db

Update README.md

e96a0f9

no need

EleisonC and others added 3 commits January 21, 2025 00:01

update readme's

6741c08

Merge branch 'master' into add-dev-chain-spec

b5fd47c

Merge branch 'master' into add-dev-chain-spec

ea2bc5b

skunert approved these changes Jan 21, 2025

View reviewed changes

EleisonC and others added 4 commits January 21, 2025 13:23

fix upload artifact path

e9f1dcd

update

de771ff

Merge branch 'master' into add-dev-chain-spec

b5f28c4

Merge branch 'master' into add-dev-chain-spec

39f471b

iulianbarbu reviewed Jan 22, 2025

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add development chain-spec file for minimal/parachain templates for Omni Node compatibility #6529

Add development chain-spec file for minimal/parachain templates for Omni Node compatibility #6529

EleisonC commented Nov 18, 2024

cla-bot-2021 bot commented Nov 18, 2024

iulianbarbu left a comment

EleisonC commented Nov 20, 2024

iulianbarbu commented Nov 20, 2024

EleisonC commented Nov 21, 2024

iulianbarbu commented Nov 21, 2024 •

edited

Loading

EleisonC commented Nov 25, 2024 •

edited

Loading

EleisonC commented Nov 26, 2024

iulianbarbu commented Nov 27, 2024

EleisonC commented Nov 27, 2024

iulianbarbu left a comment

iulianbarbu commented Jan 6, 2025 •

edited

Loading

EleisonC commented Jan 6, 2025 •

edited

Loading

EleisonC commented Jan 16, 2025

iulianbarbu left a comment •

edited

Loading

iulianbarbu commented Jan 17, 2025 •

edited

Loading

skunert left a comment

EleisonC commented Jan 18, 2025

skunert left a comment

skunert Jan 21, 2025

EleisonC Jan 21, 2025

iulianbarbu left a comment

iulianbarbu Jan 22, 2025

iulianbarbu Jan 22, 2025

iulianbarbu Jan 22, 2025

iulianbarbu Jan 22, 2025

iulianbarbu Jan 22, 2025

		- 👤 The template has no consensus configured - it is best for experimenting with a single node network.


		- For the most up-to-date chain specification, refer to [staging-chain-spec-builder](https://crates.io/crates/staging-chain-spec-builder)

	runtime_wasm_path: 'minimal-template-runtime/minimal_template_runtime.compact.compressed.wasm'
	runtime_wasm_path: 'parachain-template-runtime/parachain_template_runtime.compact.compressed.wasm'

Add development chain-spec file for minimal/parachain templates for Omni Node compatibility #6529

Are you sure you want to change the base?

Add development chain-spec file for minimal/parachain templates for Omni Node compatibility #6529

Conversation

EleisonC commented Nov 18, 2024

Description

Integration

Review Notes

cla-bot-2021 bot commented Nov 18, 2024

iulianbarbu left a comment

Choose a reason for hiding this comment

EleisonC commented Nov 20, 2024

iulianbarbu commented Nov 20, 2024

EleisonC commented Nov 21, 2024

iulianbarbu commented Nov 21, 2024 • edited Loading

EleisonC commented Nov 25, 2024 • edited Loading

EleisonC commented Nov 26, 2024

iulianbarbu commented Nov 27, 2024

EleisonC commented Nov 27, 2024

iulianbarbu left a comment

Choose a reason for hiding this comment

iulianbarbu commented Jan 6, 2025 • edited Loading

EleisonC commented Jan 6, 2025 • edited Loading

EleisonC commented Jan 16, 2025

iulianbarbu left a comment • edited Loading

Choose a reason for hiding this comment

iulianbarbu commented Jan 17, 2025 • edited Loading

skunert left a comment

Choose a reason for hiding this comment

EleisonC commented Jan 18, 2025

skunert left a comment

Choose a reason for hiding this comment

skunert Jan 21, 2025

Choose a reason for hiding this comment

EleisonC Jan 21, 2025

Choose a reason for hiding this comment

iulianbarbu left a comment

Choose a reason for hiding this comment

iulianbarbu Jan 22, 2025

Choose a reason for hiding this comment

iulianbarbu Jan 22, 2025

Choose a reason for hiding this comment

iulianbarbu Jan 22, 2025

Choose a reason for hiding this comment

iulianbarbu Jan 22, 2025

Choose a reason for hiding this comment

iulianbarbu Jan 22, 2025

Choose a reason for hiding this comment

iulianbarbu commented Nov 21, 2024 •

edited

Loading

EleisonC commented Nov 25, 2024 •

edited

Loading

iulianbarbu commented Jan 6, 2025 •

edited

Loading

EleisonC commented Jan 6, 2025 •

edited

Loading

iulianbarbu left a comment •

edited

Loading

iulianbarbu commented Jan 17, 2025 •

edited

Loading