Successive deploys to left-hand mainline environment with umbraco-cloud.json

Questions
,
1

Hi everyone,

We are working on our first Umbraco Cloud project and obviously occasionally run into some learning curve problems we have to solve. The latest one had us stumped for a bit, so I’d like to share and simultaneously ask for any advice on the topic from the more experienced Umbraco Cloud users here.

Basically, we added the umbraco-cloud.json file to our repository and in our CI/CD pipeline we modify the contents to add in the API key and client secret from our Azure DevOps secrets. After the artifacts are generated, we deploy to our Testing environment in Umbraco Cloud (the left-hand mainline environment).

This went fine during the first deploy, but successive deploys did not include updates to the file despite that the modifications were visible in the generated artifact. This in turn led to us not being able to use the Umbraco Cloud portal for deploys to Acceptance, receiving a fatal error (“Unable to read tree”).

After some deliberation and research (in addition to contacting Umbraco Support which wasn’t moving fast enough for us), we suspected that once this file is in place, it receives a sort of read-only mode where we are no longer allowed to overwrite it with our changes. To prove this theory, we entered Kudu tools and manually removed the file from Testing. Subsequently, a deploy to this environment with our pipeline resulted in our new version of the file being placed correctly in the Umbraco Cloud repository once again. We are now also able to promote the release to the next environment successfully.

Could anyone explain the reasoning behind these apparent shortcomings and perhaps advise us for the best course of action in the future? Manually deleting the file via Kudu doesn’t feel like a sustainable/reliable solution to us, so we’d be eager to hear thoughts from others on this topic.

Thanks in advance!

Kind regards,
William Parr

2

I’m not sure the file is a problem, but from what I’m reading I guess it might have started working again after you removed the file? Is that how you “fixed” it?

Ps. I would recommend using the secrets management option in the Umbraco cloud portal instead for setting up API keys and other secrets.

3

If I recall correctly the umbraco-cloud.json is just another “appsettings.json” file, so you can use the secrets mangement feature in Cloud seamlessly.

4

Hello William.

Answering from a phone :sweat_smile: The Umbraco-cloud.json file Will be overwritten during a cicd deployment with the existing file on the cloud environment. This happens to ensure that the Umbraco deploy configuration is always up to date with the current project environments.

I would add custom configuration in more conventional places like app-settings.json or use the secrets management via cloud portal.

Hope this is helpful.

Kind regards,

Jesper, Umbraco Cloud Team

5

Hi everyone, thanks for taking the time to respond to my questions and go into such detail!

I don’t think the problem is where the secrets are stored (currently in Key Vault), but the fact that we were unable to overwrite/replace the version of the file in Umbraco Cloud with modifications, once it had initially been created. Or do you expect that migrating secrets to Umbraco Cloud → Security → Secrets would mitigate similar issues in the future?

As for where to store customization of the umbraco-cloud.json file, from what I’m reading we would be able to move specific settings objects from this file to e.g. appsettings.json, as-is? In that case, what must be (left) in umbraco-cloud.json to ensure it doing what it is meant to do?

This is what we currently have in that file, where the three ${xxx} variables are of course what are being replaced during the CI/CD pipeline:

{
“Deploy”: {
“Project”: {
“Name”: “qwerty”,
“Alias”: “qwerty”,
“Id”: “xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx”,
“Url”: “``https://www.s1.umbraco.io/project/qwerty”``,
“Workspaces”: [{
“Id”: “xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx”,
“Name”: “Test”,
“Type”: “test”,
“Url”: “``https://test-qwerty.euwest01.umbraco.io``”
},
{
“Id”: “xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx”,
“Name”: “Acceptance”,
“Type”: “acceptance”,
“Url”: “``https://acceptance-qwerty.euwest01.umbraco.io``”
},
{
“Id”: “xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx”,
“Name”: “Production”,
“Type”: “production”,
“Url”: “``https://qwerty.euwest01.umbraco.io``”
}]
},
“Settings”: {
“ApiKey”: “${umbracoApiKey}”
}
},
“Identity”: {
“ClientId”: “${UIClientId}”,
“ClientSecret”: “${UIClientSecret}”,
“EnvironmentId”: “xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxxx”,
“LocalLoginRedirectUri”: “``https://redirect.identity.umbraco.com``”
}
}

Thanks again for additional insights, #h5yr :slight_smile:

6

Sorry, but I have to answer you question with a counter question :slight_smile:

Why would you want to modify the umbraco-cloud.json file in the first place?

Im asking to learn about use cases we didn’t think of - and/or to pin point documentation that needs updating. I love improving the Umbraco Docs! :sunglasses:

The umbraco-cloud.json file contains information so Umbraco Deploy can push content from local development to next-in-line cloud environment. And it contains information to allow user to still log in with Umbraco Id when working locally.

As for where to store customization of the umbraco-cloud.json file, from what I’m reading we would be able to move specific settings objects from this file to e.g. appsettings.json, as-is? In that case, what must be (left) in umbraco-cloud.json to ensure it doing what it is meant to do?

In you place I’d revert the umbraco-cloud.json back to it’s original form. I think you have the basic structure in place with the example above.
You can do a manual clone, edit, push of the environment to edit the file.

How and where you put your configuration depends on how your code is implemented. If you are using packages the documentation for the package can perhaps help you with how to structure.

But essentially I think yes, you should more or less be able to move you specific settings.

7

Hello Jesper,

We don’t want to modify the file necessarily, but in our first deployment the file was uploaded with the secrets not replaced because of an issue in the pipeline. And to fix that we had to modify it to fix it, that is when our issues began because we could not fix/modify it.

You can do a manual clone, edit, push of the environment to edit the file.

When we tried this via the clone in git we ran into an error with our pipeline “fatal: unable to read tree” so we had to revert the version there.

Hope this clarifies things.

8

I think what you are saying is that the Cloud-sync stage is failing.

When pulling down the patch file from cloud the pipeline is not able to apply it to the local file - changes between the two may be to severe for the tooling to handle.

If that is the case then here is a suggestion: Manually make sure that your repository and the cloud repository contains the files you want there. Make sure the umbraco-cloud.json file is correct on the cloud environment.

Now I think all you need is to run a cicd deployment, where you skip the cloud-sync stage but where you include one small change to the code.
Adding a small change this way will give the ci/cd feature a new latest commit-sha to generate the git-patch file from.