You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: umbraco-cloud/build-and-customize-your-solution/handle-deployments-and-environments/umbraco-cicd/samplecicdpipeline/azure-devops.md
+2Lines changed: 2 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -234,7 +234,9 @@ If you want to customize the artifact take a look at [Artifact Best Practice](..
234
234
The `cloud-deployment.yml` shows how you can deploy to a named environment of your Cloud project. The sample shows how to request the deployment and wait for cloud to finish the operation.
235
235
236
236
{% hint style="info" %}
237
+
237
238
If you have frontend assets that needs to be built (using tools like npm/yarn or others), you should add the needed steps before `cloudPrepareArtifact`. This is to ensure that the fresh frontend assets will be part of the package to be sent to Umbraco Cloud.
Copy file name to clipboardExpand all lines: umbraco-cloud/build-and-customize-your-solution/handle-deployments-and-environments/umbraco-cicd/samplecicdpipeline/github-actions.md
+4Lines changed: 4 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -83,6 +83,7 @@ Now go to the **Variables** tab
83
83
* Create a `repository variable` called `TARGET_ENVIRONMENT_ALIAS` and enter the environment alias you selected earlier.
84
84
85
85
{% hint style="info" %}
86
+
86
87
If you want to use other names for the secrets and variables, you need to rename the `secrets` and `with` variables in each of `main.yml`'s jobs.
87
88
88
89
```yaml
@@ -110,6 +111,7 @@ jobs:
110
111
with:
111
112
targetEnvironmentAlias: ${{ vars.TARGET_ENVIRONMENT_ALIAS }} # change the part inside the curly braces
112
113
```
114
+
113
115
{% endhint %}
114
116
115
117
Now GitHub is set up with the needed information to be able to run a deployment back to Umbraco Cloud.
@@ -264,7 +266,9 @@ If you want to customize the artifact take a look at [Artifact Best Practice](..
264
266
The `cloud-deployment.yml` shows how you can deploy to a named environment of your Cloud project. The sample shows how to request the deployment and wait for cloud to finish the operation.
265
267
266
268
{% hint style="info" %}
269
+
267
270
If you have frontend assets that needs to be built (using tools like npm/yarn or others), you should add the needed steps before `cloud-artifact`. This is to ensure that the fresh frontend assets will be part of the package to be sent to Umbraco Cloud.
Copy file name to clipboardExpand all lines: umbraco-cloud/build-and-customize-your-solution/handle-deployments-and-environments/umbraco-cicd/troubleshooting.md
+9-9Lines changed: 9 additions & 9 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -26,7 +26,7 @@ The mechanism to determine changes since the last deployment is not able to do s
26
26
}
27
27
```
28
28
29
-
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.
29
+
You need to _manually_ make sure that all latest changes on your left-most mainline environment is also present in your local copy.
30
30
31
31
Once this is done you can run a new deployment, where you skip the cloud-sync step.
32
32
@@ -58,8 +58,8 @@ Once that has been done, you should run a new deployment without the `cloud-sync
58
58
For Azure DevOps, see the [Skip cloud-sync in Azure DevOps](troubleshooting.md#skip-cloud-sync-in-azure-devops) section.
59
59
60
60
1. Ensure your GitHub repository is up-to-date with any changes in your Umbraco Cloud environment.
61
-
2. Locate the main.yml file in the following directory: {projectname}.github\workflows on tour local project.
62
-
3. Open the main.yml file in a text editor and navigate to the “jobs” section.
61
+
2. Locate the `main.yml` file in the following directory: `{projectname}.github\workflows` on tour local project.
62
+
3. Open the `main.yml` file in a text editor and navigate to the “jobs” section.
63
63
4. Comment out the entire “cloud-sync” section and the “needs: cloud-sync” under “cloud-deployment”. An example is provided in the screenshot below.
@@ -108,11 +108,11 @@ You can see an example of how you could zip your repository before uploading it,
108
108
109
109
## Deployment failed
110
110
111
-
### File missing: The .umbraco file cannot be found in the root of the repository
111
+
### File missing: The `.umbraco` file cannot be found in the root of the repository
112
112
113
113
The `.umbraco` file is missing or has been renamed. This file needs to be present in the root of the zipped package.
114
114
115
-
### File format Error: The .umbraco file is not valid
115
+
### File format Error: The `.umbraco` file is not valid
116
116
117
117
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.
118
118
@@ -142,7 +142,7 @@ We recommend aligning the package versions in your _.csproj_ files with the high
142
142
143
143
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.
144
144
145
-
### Could not find '/app/work/repository/Readme.md' to stat: No such file or directory
145
+
### Could not find `/app/work/repository/Readme.md` to stat: No such file or directory
146
146
147
147
In some instances we see an issue where filename casing is causing an error.
148
148
@@ -170,18 +170,18 @@ Once the marker file is removed, run your pipeline again.
170
170
171
171
### Unable to determine environment by its {environment-id}
172
172
173
-
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:
173
+
This happens when using CI/CD 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:
174
174
175
175
```
176
176
“System.InvalidOperationException: Unable to determine environment by its {environment-id}”
177
177
```
178
178
179
-
This issue arises because the environment is missing in the local umbraco-cloud.json file. To resolve this issue, follow these steps:
179
+
This issue arises because the environment is missing in the local `umbraco-cloud.json` file. To resolve this issue, follow these steps:
180
180
181
181
1. Navigate to Kudu in your Live environment
182
182
2. Select “Debug console” and choose “CMD”.
183
183
3. 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
184
184
4. Click ‘edit’ on the file and copy all its content. This content is consistent across environments, so it’s safe to do so.
185
-
5. Paste the copied content into the umbraco-cloud.json file in your local project and push the changes.
185
+
5. Paste the copied content into the `umbraco-cloud.json` file in your local project and push the changes.
186
186
187
187
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.
Copy file name to clipboardExpand all lines: umbraco-cloud/build-and-customize-your-solution/handle-deployments-and-environments/umbraco-cicd/umbracocloudapi.md
+17-13Lines changed: 17 additions & 13 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -2,9 +2,8 @@
2
2
3
3
The Umbraco Cloud API serves as a publicly accessible endpoint that customers can utilize to execute relevant tasks.
4
4
5
-
While its initial focus is on automating and managing deployments in Umbraco Cloud projects via the "Umbraco CI/CD Flow," future enhancements will broaden its capabilities to encompass a wider range of activities and options for Umbraco Cloud users.
6
-
7
5
{% hint style="info" %}
6
+
8
7
### Changes between endpoints for version 1 and 2
9
8
10
9
With the endpoints for version 2, you are given more control over the process.
@@ -17,7 +16,8 @@ These are the most important differences between the V1 and V2 endpoints:
17
16
18
17
[Do you want to migrate from V1 to V2 endpoints?](samplecicdpipeline/migrate.md)
19
18
20
-
The V1 endpoints are still available, you can see the [V1 api documentation here](v1-umbraco-cloud-api.md).
19
+
[The V1 endpoints are still available](v1-umbraco-cloud-api.md).
20
+
21
21
{% endhint %}
22
22
23
23
## Getting started
@@ -53,8 +53,9 @@ The two elements to be used for the authentication are:
53
53
54
54
By including the API key header in your HTTP requests, you ensure secure access to your Umbraco Cloud project's resources.
55
55
56
-
For enhanced security, it's crucial to store the provided API key in a secure location. Options include a variable group in Azure DevOps or using the Secrets feature in GitHub Actions.\
57
-
It's important to note that each API key is tightly coupled with a specific Umbraco Cloud project and can only be used for deployments related to that project.
56
+
For enhanced security, it's crucial to store the provided API key in a secure location. Options include a variable group in Azure DevOps or using the Secrets feature in GitHub Actions.
57
+
58
+
Each API key is tightly coupled with a specific Umbraco Cloud project and can only be used for deployments related to that project.
58
59
59
60
### How to authenticate your requests
60
61
@@ -231,16 +232,16 @@ The response from the API should be an HTTP 201 Created response including a `de
231
232
You can use the deploymentId to query the Get Deployment status endpoint.
232
233
233
234
{% hint style="info" %}
234
-
It is not recommended to enable the `skipVersionCheck`. This is to ensure that versions of the various Umbraco packages in the Cloud environment aren't overwritten by older versions. However, there may be instances where you would like to deploy an older artifact, and for those cases, it is possible to enable this setting to skip the step.
235
+
It is not recommended to enable the `skipVersionCheck`. This is to ensure that versions of the different Umbraco packages in the Cloud environment aren't overwritten by older versions. There may be instances where you would like to deploy an older artifact. In those instances it is possible to enable this setting to skip the step.
235
236
236
-
Enabling the `noBuildAndRestore` only disabled the restore and build inside the isolated instance. Once the system pushes the source code to the environment, the regular Cloud flow takes over, and a build and publish operation will run as usual. One minute or more can be saved during the deployment process by enabling this option.
237
+
Enabling the `noBuildAndRestore` only disabled the restore and build inside the isolated instance. Once the system pushes the source code to the environment a build and publish operation will run as usual. One minute or more can be saved during the deployment process by enabling this option.
237
238
{% endhint %}
238
239
239
240
### Get Deployment status
240
241
241
-
To monitor the status of a deployment, you can periodically query the 'Get Deployment Status' API. This API endpoint is an HTTP GET request to the Umbraco Cloud API, and it requires both the `projectId` and the `deploymentId` obtained from previous steps to be included in the path.
242
+
To monitor the status of a deployment, you can periodically query the 'Get Deployment Status' API. This API endpoint is an HTTP GET request to the Umbraco Cloud API. It requires both the `projectId` and the `deploymentId` obtained from previous steps to be included in the path.
242
243
243
-
Deployments in Umbraco services can take varying amounts of time to complete. Therefore, it's advisable to poll this API at regular intervals to stay updated on the deployment's current state. For example, in a simple project, you might choose to poll the API every 25 seconds for a duration of 15 minutes. These figures are just a starting point; the optimal polling frequency and duration may differ for your specific pipeline.
244
+
Deployments in Umbraco services can take varying amounts of time to complete. Therefore, it's advisable to poll this API at regular intervals to stay updated on the deployment's current state. For example, you might choose to poll the API every 25 seconds for a duration of 15 minutes. These figures are a starting point. The optimal polling frequency and duration may differ for your specific pipeline.
244
245
245
246
A new query parameter has been added to limit the deploymentStatusMessages. As a value for the query parameter you can use the `modifiedUtc` value from a previous response.
The response from this API call will return the same deployment object in JSON format as you would receive from other API interactions. Ultimately, the `deploymentState` field will indicate either 'Completed' or 'Failed'.\
261
+
The response from this API call will return the same deployment object in JSON format as you would receive from other API interactions. Ultimately, the `deploymentState` field will indicate either 'Completed' or 'Failed'.
262
+
261
263
Should the deployment fail, check the `deploymentStatusMessages` for more information.
The API response will vary based on whether or not there are changes to report. If no changes are detected, you'll receive an HTTP 204 No Content status. On the other hand, if there are changes, the API will return an HTTP 200 OK status along with a git-patch file as the content. This git-patch file can then be applied to your local repository to sync it with the changes.
358
+
The API response will vary based on whether or not there are changes to report. If no changes are detected, you'll receive an HTTP 204 No Content status. If there are changes, the API will return an HTTP 200 OK status along with a git-patch file as the content. This git-patch file can then be applied to your local repository to sync it with the changes.
357
359
358
360
{% hint style="info" %}
359
-
It is only possible to generate git-patch files when the selected `deploymentId` points to a deployment where the `targetEnvironmentAlias` then, is the same as in this request.
361
+
362
+
It is only possible to generate git-patch files when the selected `deploymentId` points to a deployment where the `targetEnvironmentAlias` is the same as in this request.
363
+
360
364
{% endhint %}
361
365
362
366
## Possible errors
363
367
364
-
When interacting with the Umbraco Cloud API, you may encounter various HTTP status codes that indicate the success or failure of your API request. Below is a table summarizing the possible status codes, their corresponding errors, and basic root causes to guide your troubleshooting:
368
+
When interacting with the Umbraco Cloud API, you may encounter HTTP status codes that indicate the success or failure of your API request. Below is a table summarizing the possible status codes, their corresponding errors, and basic root causes to guide your troubleshooting:
0 commit comments