[CI/CD] Chances the online website cannot be accessed after deploy

[tyn1998]

Several days ago we encountered it. Now twice:

Network tab in DevTools:

...folded content:

[tyn1998]

But can be accessed by https://open-leaderboard.x-lab.info/static/js/

...folded content:

Do you think it might be caused by a wrongly set cache strategy? @zhicheng-ning

[zhicheng-ning]

@gymgym1212 Do you know whyopen-leaderboard.x-lab.infowill be resolved by CNAME to open-leaderboard.x-lab.info.w.kunlunaq.com ?

[frank-zsy]

I config the DNS since the OpenLeaderboard is hosted on CDN service but not simply OSS. The CNAME is the CDN address for corresponding OSS. So I don't think it is something wrong about the DNS, maybe caused by CDN cache strategy. @zhicheng-ning

[zhicheng-ning]

The CNAME is the CDN address for corresponding OSS.

ok

[bifenglin]

CNAME is used to map another domain, and usually could be found in DNS. And I think the reason is the Nginx config. Plz delete the zip function in nginx.conf file which located in /etc/nginx.

[frank-zsy]

Not sure what you mean but we build and publish the website directly to OSS and add a DNS service on it, so we don't host any Nginx service on ourselves. @bifenglin

[bifenglin]

I'm not sure about the deployment architecture. And I don't know this method to deploy, I will ask to @tyn1998 face-to-face. And thanks for reply @frank-zsy .

publish the website directly to OSS and add a DNS service on it

[frank-zsy]

Here is the publish action: https://github.com/X-lab2017/open-leaderboard/blob/main/.github/workflows/publish.yml

[tyn1998]

I have read:

• https://help.aliyun.com/document_detail/123227.html

• https://help.aliyun.com/document_detail/27140.htm?spm=a2c4g.11186623.0.0.2f266c53qCkfM2#task-187634

• 刷新任务从提交到生效，大约需要5~6分钟，
• 预热任务从提交到预热完成，实际执行时间视预热文件大小而定，大约需要5~30分钟。

• https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control
• https://github.com/gymgym1212/delete-oss/blob/main/index.js

Still cannot have a conclusion, but I suspect that delete-oss before update-oss might be the cause:

open-leaderboard/.github/workflows/publish.yml

Lines 28 to 44 in 1af79f3

	- name: Clean up OSS
	uses: gymgym1212/delete-oss@main
	with:
	key-id: ${{ secrets.OSS_ACCESS_KEY_ID }}
	key-secret: ${{ secrets.OSS_ACCESS_KEY_SECRET }}
	region: ${{ secrets.OSS_REGION }}
	bucket: ${{ secrets.OSS_BUCKET }}
	- name: Publish to OSS
	uses: tvrcgo/upload-to-oss@master
	with:
	key-id: ${{ secrets.OSS_ACCESS_KEY_ID }}
	key-secret: ${{ secrets.OSS_ACCESS_KEY_SECRET }}
	region: ${{ secrets.OSS_REGION }}
	bucket: ${{ secrets.OSS_BUCKET }}
	assets: |
	./build/**:${{ secrets.OSS_TARGET_PATH }}

I don't think a delete operation is necessary as the old files should be covered by new ones.

[tyn1998]

#66 removed code of delete-oss, but it didn't bring any change of built files so the files on the oss remained the same(i.e. main.xxxx.js is still main.xxxx.js).

Following merges into main should be observed to test if the problem is resolved.

[frank-zsy]

@tyn1998 It could be the problem. Delete the files first because for the generated files, I am not sure but perhaps the numbers are random number by building timestamp. So if we do not clean the files in time, there will be lots of legacy files left on OSS.

[tyn1998]

Hi @frank-zsy, do you have access to the oss console? Would you mind checking if old files were simply covered? Since main.xxxx.js and some other files are in the /static folder I think they will be removed when the /static folder is covered by a new one.

I am not sure but perhaps the numbers are random number by building timestamp.

xxxx of main.xxxx.js is file content related, not generated randomly. So xxxx will remain the same if there is no JS change in the codebase between two builds.

[frank-zsy]

Hi @frank-zsy, do you have access to the oss console? Would you mind checking if old files were simply covered? Since main.xxxx.js and some other files are in the /static folder I think they will be removed when the /static folder is covered by a new one.

Upload a folder to the OSS will cover the old files with same name but do not remove old files unless explicitly remove them like in the action. Actually I think we can set some flag to remove old files on upload but not in 2 steps, although this may cause file inconsistent for a short time.