Troubleshooting
Last updated
Was this helpful?
Last updated
Was this helpful?
RestorePackagesWithLockFile in your .csproj fileIf RestorePackagesWithLockFile is used and set to true, you will experience that no changes will be made to the website. This happened even though the CI/CD deployments were completed successfully, and files were updated as expected in the Cloud repository.
The reason for this is that the KUDU deploy process fails. This process takes the newly committed files from the cloud repository and runs restore, build, and publish on the cloud environment.
To resolve this issue, remove the RestorePackagesWithLockFile to allow the deployments to go through as expected.
The mechanism to determine changes since the last deployment is not able to do so when the left-most mainline environment has changed. This happens when you either add or remove a mainline environment. The responds with status 409 and the following json payload:
You will need to manually make sure that all latest changes on your left-most mainline environment in cloud is also present in your local copy.
Once this is done you can run a new deployment, where you skip the cloud-sync step.
The sample pipelines are naively trying to apply any change coming from the generated patch file on cloud. This doesn't always work and you might see an error similar to the following:
The root cause is due to conflicts between your source and the code in the repository on Umbraco Cloud. This is usually due to one of two things:
Cloud project package(s) has been auto-upgraded, and that diff was already applied.
In both cases you have to make sure that your repository is up too speed with any changes there are in the cloud environment. You will have to resolve potential conflicts manually.
Once that has been done, you should run a new deployment without the cloud-sync step.
Ensure your GitHub repository is up-to-date with any changes in your Umbraco Cloud environment.
Locate the main.yml file in the following directory: {projectname}.github\workflows on tour local project.
Open the main.yml file in a text editor and navigate to the “jobs” section.
Comment out the entire “cloud-sync” section and the “needs: cloud-sync” under “cloud-deployment”. An example is provided in the screenshot below.
Commit the changes, and push them to GitHub. This action will trigger a build and run the pipeline.
At this point, the pipeline should execute successfully and your changes will be pushed to Umbraco Cloud. If this is the case, proceed to the next step.
Uncomment the lines you previously commented out and make a new commit. Push these changes to GitHub.
Optional: Add "[skip ci]" to the last commit message, to avoid automatically triggering the pipeline
Your pipeline should now be functioning as expected.
With a few clicks you can manually trigger a pipeline to run without the cloud-sync:
Ensure that your Azure DevOps repository is up to date with any changes in your Umbraco Cloud environment.
Find the pipeline in Azure DevOps.
Click on "Run Pipeline" in the top right corner.
Click on "Stages to run"
Uncheck the "Umbraco Cloud Sync" checkbox. Confirm on "Use selected stages".
Click on "Run" back in the "Run Pipeline" view.
As no changes were made to your pipeline, it will run as usual on next push to Azure DevOps.
We currently have a size limit set to 134217728 bytes or about ~128 MB.
Make sure that the package you are trying to upload does not contain anything unnecessary.
The .umbraco file is missing or has been renamed. This file needs to be present in the root of the zipped package.
The .umbraco file has invalid characters. Sometimes people need to change the repository's folder structure and the default project's name. Ensure that the base field does not use backslashes ('') as the folder denominator.
Below is an example of the default .umbraco file that comes with a new Umbraco Cloud project.
The service goes through all .csproj-files contained in the uploaded package, and compares that to the versions running in your left-most cloud environment. We do this to try to prevent you from downgrading the crucial Umbraco packages used by cloud.
The full error could look like this:
The error tells you which package to look for and which version is currently in your left-most cloud environment. The error also contains the problematic incoming .csproj-file and the version referenced by it.
If the incoming package references multiple packages with lower versions, the error will list each one.
We recommend aligning the package versions in your .csproj files with the higher version mentioned in the error for that package or a later version.
If you have orphaned csproj-files you should remove them or rename them. Orphaned would be backup .csproj files or files not referenced by any of the main project files nor referenced in a .sln file.
In some instances we see an issue where filename casing is causing an error.
Rename the Readme.md file in the root of your repository to something different, the file can keep the markdown-extension. Commit the change to your repository and run the pipeline.
If you want you can change the filename back to Readme.md after a successful CI/CD deployment.
In rare cases deployments fail, and the cloud infrastructure doesn't clean up correctly. This leaves behind an "updating" marker. The next time you try to deploy through your pipeline you will encounter an error.
Access KUDU on the "left-most" environment
If you only have one environment you want the live environment
If you have more than one environment, you want the left-most mainline environment
Navigate to site > locks folder In there, there should be a file named updating
Remove the updating file.
Once the marker file is removed, run your pipeline again.
This happens when you use the CI/CD feature of Umbraco Cloud to deploy changes to your live environment, and later add a new Cloud environment. Your environment will fail to boot up and will show the following error message:
This issue arises because the environment is missing in the local umbraco-cloud.json file. To resolve this issue, follow these steps:
Navigate to Kudu in your Live environment
Select “Debug console” and choose “CMD”.
Find the umbraco-cloud.json file. Path to this file may vary depending on your setup, but the default location on cloud is C:\home\site\repository\src\UmbracoProject
Click ‘edit’ on the file and copy all its content. This content is consistent across environments, so it’s safe to do so.
Paste the copied content into the umbraco-cloud.json file in your local project and push the changes.
After completing these steps, your left-most mainline environment should be correctly registered across all environments, allowing you to continue your work without any issues.
If you experience problems with your environment not properly booting up after deployment, .
You and your team are not following the .
For Azure DevOps, see the section.
For GitHub, see the section.
You can see an example of how you could zip your repository before uploading it, by referring to our or samples.
In order to fix this issue, you need to use to remove the leftover marker file.
