It can be useful to have a staging or testing environment for your GitHub Enterprise Server instance, so that you can test updates or new features before implementing them in your production environment.
A common way to create the staging environment is to use a backup of your production instance and restore it to the staging environment.
When setting up a GitHub Enterprise Server staging environment that has GitHub Actions enabled, you must use a different external storage configuration for GitHub Actions storage than your production environment uses. Otherwise, your staging environment will write to the same external storage as production.
Expect to see 404 errors in your staging environment when trying to view logs or artifacts from existing GitHub Actions workflow runs, because that data will be missing from your staging storage location.
Although it is not required for GitHub Actions to be functional in your staging environment, you can optionally copy the files from the production storage location to the staging storage location.
-
For an Azure storage account, you can use
azcopy. For example:azcopy copy 'https://SOURCE-STORAGE-ACCOUNT-NAME.blob.core.windows.net/SAS-TOKEN' 'https://DESTINATION-STORAGE-ACCOUNT-NAME.blob.core.windows.net/' --recursive -
For Amazon S3 buckets, you can use
aws s3 sync. For example:aws s3 sync s3://SOURCE-BUCKET s3://DESTINATION-BUCKET