Skip to content

Unable to deploy when MNTP has a start node #219

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
AaronSadlerUK opened this issue May 24, 2024 · 2 comments
Open

Unable to deploy when MNTP has a start node #219

AaronSadlerUK opened this issue May 24, 2024 · 2 comments
Labels
state/sprint-candidate We're trying to get this in a sprint at HQ in the next few weeks type/bug

Comments

@AaronSadlerUK
Copy link

When deploying MNTP data types containing a start mode from local to development, this will cause deploy to fail.

Reproduction

Steps to reproduce

Create a MNTP data type
Set a start node to content not on Cloud
Deploy

Expected result

Deploy should either create the datatype and ignore the fact the content doesn't exist, this would allow for the content to be pushed up after.
Or deploy should log a useful error message to say that the content X (X being the guide / key) could not be found, this however on it's own would cause deploy to be blocked, so the error should mention about removing the start node until the content is deployed.

Actual result

Deploy fails with no useful error, it only states the document type is missing a data type, it doesn't give a reason why the data type has not been deployed

@AndyButland AndyButland added type/bug state/sprint-candidate We're trying to get this in a sprint at HQ in the next few weeks labels May 31, 2024
@AndyButland
Copy link

I've checked this over in the latest version of Deploy 13, but not seeing the problem here.

Here's the steps I've taken so they can be verified:

  • Created a new doc type to act as a folder of items
  • Create a new doc type to act as the item
  • Allowed the item under the folder
  • Created the content
  • Created a new data type, a multi-node tree picker and set the root node as the folder
  • Deployed the schema to the upstream environment.

I found everything was created OK, but if you go to the definition of the data type you see this error, as it can't find the content.

image

But once the content is deployed, it's all good.

Perhaps we could consider adding a dependency to the content item from the data type? But I'm not sure that would be a better experience. You would then get an error when doing a schema update (e.g. after a git push to Cloud). Would then have to deploy the necessary content in order to then re-trigger the extraction. But if that content depends on other schema items that are pending, we could end up getting in a circular issue that would be tricky to manually resolve. So probably what happens here already - where the schema is created, with the reference to a missing root node is the best approach to take.

@ronaldbarendse
Copy link

The root of the issue is really in the fact that schema (like a data type) can require a content item to exist, but might need to be deployed first to be able to successfully deploy that content, resulting in a cyclic dependency.

For this to be the case though, Deploy needs to be aware/understand the dependencies between items. This is done through value connectors (for content properties) and data type configuration connectors, but neither Deploy 13 or Deploy Contrib 13 have an IDataTypeConfigurationConnector implementation for the MNTP. It does have one for the Content Picker, but that only adds the start node as an 'optional' dependency.

As Andy couldn't replicate the issue, my guess is that something else caused the data type to not be deployed successfully and that subsequently results in a schema mismatch, preventing you from transferring content.

Can you share the versions of the CMS, Deploy and Deploy Contrib and check the deploy status (either in umbraco\Deploy or the log viewer) on both environments? And also make sure you've followed the documented troubleshooting steps to ensure both environments are in a consistent state first!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
state/sprint-candidate We're trying to get this in a sprint at HQ in the next few weeks type/bug
Projects
None yet
Development

No branches or pull requests

3 participants