chore(preview-envs): Build workflows to deploy and tear down preview …

[andromaqui]

…envs

Description

This pr aims to add the following functionality:

• create a workflow to deploy preview envs
• creates a workflow to tear down preview envs
• modify the url & baseurl of docusaurus

When should this change go live?

• This is a bug fix, security concern, or something that needs urgent release support.
• This is already available but undocumented and should be released within a week.
• This on a specific schedule and the assignee will coordinate a release with the DevEx team. (apply hold label or convert to draft PR)
• This is part of a scheduled alpha or minor. (apply alpha or minor label)
• There is no urgency with this change and can be released at any time.

PR Checklist

• My changes are for an already released minor and are in /versioned_docs directory.
• My changes are for the next minor and are in /docs directory (aka /next/).

• My changes require an Engineering review, and I've assigned the Engineering DRI or delegate.
• My changes require a technical writer review, and I've assigned @camunda/tech-writers as a reviewer.

NOTES:

• The preview-env-deployworkflow is set to timeout in 30 mins because some builds took a bit more than 20 mins. I thought it might make sense to not have the timeout too tight
• In the preview-env-deploy in the Build step, I tried passing the bucket name prepended by https:// to node but node couldnt read it for some reason:
  DOCS_SITE_URL: https://${{ steps.secrets.outputs.PREVIEW_ENV_BUCKET_NAME }}
  The only logical explanation I could think of is that there might an issue when one concatenates a string to a secret so I therefore did the processing in the docausaurus.config.js file

TESTING:

Test 1: Test that the preview env can be deployed and the link works when adding a label

• I did this test with the help of this pr. When removing the label the comment gets replaced and the preview env gets cleaned up so I wouldnt be able to do it in the same pr. The files has been uploaded in this path of the google bucket.

Test 2: Test that the preview env gets cleaned up when removing the label

See the comment below which replaces the original comment with a new one indicating that the deployment has been cleaned up

[github-actions]

Your preview env has been teared down.

[pepopowitz]

I'm not sure if you're ready for a review from us at DX, but here are some things I noticed:

1. In chore(preview-envs): Build workflows to deploy and tear down preview env #3945, for some reason the successful deploy-preview-env check links to https://github.com/camunda/camunda-docs/actions/runs/9515008389/job/26228377770?pr=3945, which is actually the workflow from TEST: chore(preview-envs): Build workflows to deploy and tear down preview env #3946, not chore(preview-envs): Build workflows to deploy and tear down preview env #3945. I only noticed this because I was inspecting logs for issues mentioned further down, and I saw that it mentioned pr-3946. This is not a blocking issue, but it is strange, and if you have any ideas why it might be happening, fixing it would likely save us confusion in the future.
2. The site deployed by chore(preview-envs): Build workflows to deploy and tear down preview env #3945 did not build properly: https://preview.docs.camunda.cloud/pr-3945/index.html. Note the error message at the top from Docusuarus, and a lack of styling.
3. The Docusaurus baseUrl suggestion in that error is strange -- the assets are all available at the baseUrl that was specified at build time, the path recommended by Docusaurus is nonsense (/pr-3945/index.html/assets/....). I think this recommendation is probably a symptom, not the cause of the issue.
4. The lack of styling is also surprising, but it appears to be happening because many assets are missing in the published bucket, including the site's CSS file.

   • Surprising, because in the logs for this deployment, it appears that the assets.[thumbprint].css file was mentioned in the "Upload files to google bucket" step:

     

   • Also strange is that when I compare the bucket contents for this build compared to a previous PR's bucket still out there, there are many things missing from the assets folder:

     

   • When I visit the site for that previous preview deployment, it looks good.

5. There are a few other missing assets in chore(preview-envs): Build workflows to deploy and tear down preview … #3928's functioning deployment, like icons in the footer and a non-critical BPMN JavaScript file, but those are on me to fix 😅, and shouldn't block this PR.

[pepopowitz]

Suggested change

	Your preview env has been teared down.
	Your preview env has been torn down.

[github-actions]

Your preview env has been torn down.

[andromaqui]

@pepopowitz Thank you for bringing these observations to my attention. Here is a few things which came out of my investigation:

1. I am not very sure how this could have happened, it is indeed quite weird. The last runs I triggered in the pull requests chore(preview-envs): Build workflows to deploy and tear down preview env #3945 and chore(preview-envs): Build workflows to deploy and tear down preview … #3947 reference correctly the respective pr I believe:

#3945: https://github.com/camunda/camunda-docs/actions/runs/9550158152/job/26321466061?pr=3945
#3947: https://github.com/camunda/camunda-docs/actions/runs/9515486762/job/26229804120?pr=3947

2,3,4: I have been trying to understand how this happened as I very vividly remember tripple checking all the changes and this issue was not apparent last time I visited the pr #3945 I believe. To understand better what happened, I removed added again the label in the pr #3945 and it seems to be that the preview env can be accessed fine. I did some additional testting and it seems to me that if some of the files gets deleted for some reason from the bucket the error you saw can appear. My assumption is that maybe when I removed the label in the pr #3945 although I stopped the [teardown workflow ] (https://github.com/camunda/camunda-docs/actions/runs/9515351835/job/26229414354?pr=3945) manually and it shows that no deletion happened, it mighr be the case that it indeed deleted some of the data.

Or someone went in the bucket and deleted them manually because as you saw in the logs they have been uploaded.

5. This is actually a closed test pr which I was working with and is not meant to be taken into consideration as this preview environment has been teared down.

My overall feeling is that either there is an actual underlying problem or I might have messed up the workflow runs somehow since I was running a lot of tests in parallel. I will continue testing this today.

[github-actions]

Preview environment has successfully been deployed. You can access it on https://preview.docs.camunda.cloud/pr-3947/index.html.

[github-actions]

Preview environment has successfully been deployed. You can access it on https://preview.docs.camunda.cloud/pr-3947/index.html.