Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
tyn1998 opened this issue Feb 22, 2023 · 13 comments
Open

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

tyn1998 opened this issue Feb 22, 2023 · 13 comments

Comments

@tyn1998
Copy link
Member

tyn1998 commented Feb 22, 2023

Several days ago we encountered it. Now twice:

image

Network tab in DevTools:

image

...folded content:

image

@tyn1998
Copy link
Member Author

tyn1998 commented Feb 22, 2023

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

image

...folded content:

image

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

@zhicheng-ning
Copy link
Member

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

5574ccd432a08686905b6ee300f3120

@frank-zsy
Copy link
Contributor

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
Copy link
Member

The CNAME is the CDN address for corresponding OSS.

ok

@bifenglin
Copy link
Contributor

bifenglin commented Feb 23, 2023

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
Copy link
Contributor

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
Copy link
Contributor

bifenglin commented Feb 23, 2023

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
Copy link
Contributor

@tyn1998
Copy link
Member Author

tyn1998 commented Feb 23, 2023

I have read:

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

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

- 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
Copy link
Member Author

tyn1998 commented Feb 23, 2023

#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
Copy link
Contributor

@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
Copy link
Member Author

tyn1998 commented Feb 24, 2023

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
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants