Skip to content
This repository has been archived by the owner on Mar 4, 2023. It is now read-only.

Issue with parent ids not being consistent across CI runs #7

Closed
jonathantwite opened this issue Mar 5, 2020 · 1 comment
Closed
Assignees
Labels
bug Something isn't working

Comments

@jonathantwite
Copy link

jonathantwite commented Mar 5, 2020

When CI is run on different computers, the NodeIDs being assigned are not necessarily consitent. Therefore the matching of parent nodes by id here is not working.

Suggest changing to matching by NodeParentGUID instead.

@CMeeg CMeeg self-assigned this Mar 8, 2020
@CMeeg CMeeg added the bug Something isn't working label Mar 8, 2020
@CMeeg
Copy link
Owner

CMeeg commented Mar 9, 2020

Thanks for raising this @jonathantwite :)

TL;DR - Please install v0.3.1 of the NuGet packages and your issue should hopefully be resolved!

Setting the NodeParentID when persisting the component data was originally done to support adding "Pages" fields to components because the relationships need to reference the component's "parent" node rather than the component itself. NodeParentID is an existing property on TreeNode so it was convenient to use that rather than adding more of my own code, but I hadn't thought about this scenario!

I thought of a few ways to tackle it:

  1. Don't persist the NodeParentID and just set it when instantiating the component at runtime
  2. Use a custom field to store a guid reference to the "parent" or some other reference that will persist between CI runs (as you have suggested)
  3. Try to hook into the relevant CI operations and "translate" the NodeParentID to the appropriate value when CI is executed

I decided against option 2 because it doesn't feel like I should have to add additional fields to get the "parent" when there are already existing properties for doing that - I'm not dead set against this, but it just didn't "feel" right.

I went for option 1 in the end though there is a slight cost to this if you use nested components (i.e. components that themselves have components) as the code will walk up the tree until it finds the first "parent" that isn't a component. For "top-level" components though (the most common scenario from what I can gather of people using this module) the component is resolved in the context of the "parent" so setting the reference at runtime is a straight-forward assignment.

I have also raised issue #8 to investigate option 3 as that feels like a "better" option though a) there is a blocker in me investigating that due to not having a CI-enabled license for this project; and b) it felt like potentially a lot of effort for not much additional value (at this point at least)!

v0.3.1 of the packages have been released to NuGet with the changes to support option 2 - hopefully this will resolve your issue :)

@CMeeg CMeeg closed this as completed Mar 9, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants