nodejs / nodejs.org

The Node.jsยฎ Website
https://nodejs.org
MIT License
5.99k stars 6.15k forks source link

CI: Orama cloud sync based on environment #6824

Closed canerakdas closed 2 weeks ago

canerakdas commented 3 weeks ago

Description

In the previous PRs opened (#6814, #6806), we ensured that the Orama cloud sync script updates the preview environment on push and pull_request_target events.

With this PR, we aim to update the production indexes using this script on the push event instead of manually updating it and to update the preview environment on pull_request_target events.

Additionally, to prevent these scripts from running twice, we ensure they only run on ubuntu-latest runners. Since we are currently running it on windows-latest in the preview environment, the facets are currently not displayed correctly, likely due to differences in paths on Windows (You can check it in a sample preview build)

Before merging this development, the ORAMA_PRODUCTION_INDEX_ID and ORAMA_PRODUCTION_SECRET_KEY secrets need to be defined. I believe we should get support from @ovflowd or @bmuenzenmeyer for this ๐Ÿ‘€ I think we should first set these two values to point to the preview environment to ensure everything is working correctly, and then replace them with the production ones

Additionally, it would be helpful to ask the Orama team if indexing on every pull_request_target and push events would cause any issues on their side

Related Issues

Related to #6719

vercel[bot] commented 3 weeks ago

The latest updates on your projects. Learn more about Vercel for Git โ†—๏ธŽ

Name Status Preview Updated (UTC)
nodejs-org โœ… Ready (Inspect) Visit Preview Jun 9, 2024 8:37pm
ovflowd commented 3 weeks ago

Before merging this development, the ORAMA_PRODUCTION_INDEX_ID and ORAMA_PRODUCTION_SECRET_KEY secrets need to be defined. I believe we should get support from @ovflowd or @bmuenzenmeyer for this ๐Ÿ‘€ I think we should first set these two values to point to the preview environment to ensure everything is working correctly, and then replace them with the production ones

Secrets Added ๐Ÿ––

ovflowd commented 3 weeks ago

Additionally, it would be helpful to ask the Orama team if indexing on every pull_request_target and push events would cause any issues on their side

cc @micheleriva

micheleriva commented 3 weeks ago

@ovflowd that looks good to me!

bmuenzenmeyer commented 3 weeks ago

hmm - comparing experiences, the proposed search has odd headers

image

ovflowd commented 3 weeks ago

Not sue why the discrepancies, this PR doesn't affect the website at all...

canerakdas commented 2 weeks ago

hmm - comparing experiences, the proposed search has odd headers

As far as I understand; the current script works for windows-latest and ubuntu-latest. However, since windows-latest runs later and the paths in the file located at this path come as shown in the image below;

image

The split in this line does not work correctly. Therefore, the script that runs later overwrites the index created in ubuntu-latest, corrupting the existing indexes

Since we will only run this script on ubuntu-latest, I think there won't be such an issue after merging this PR. Since the current production secrets are replaced with the preview ones, it would be beneficial to run pull_request_target event in a different PR after this PR is merged and recheck the preview to ensure everything is working correctly ๐Ÿ‘€

bmuenzenmeyer commented 2 weeks ago

Good analysis @canerakdas - I'm willing to get it a go today if we're all around to watch

github-actions[bot] commented 2 weeks ago
Lighthouse Results URL Performance Accessibility Best Practices SEO Report
/en ๐ŸŸ  87 ๐ŸŸข 100 ๐ŸŸข 100 ๐ŸŸข 91 ๐Ÿ”—
/en/about ๐ŸŸข 100 ๐ŸŸข 100 ๐ŸŸข 96 ๐ŸŸข 91 ๐Ÿ”—
/en/about/previous-releases ๐ŸŸข 96 ๐ŸŸข 100 ๐ŸŸข 100 ๐ŸŸข 92 ๐Ÿ”—
/en/download ๐ŸŸข 99 ๐ŸŸข 100 ๐ŸŸข 100 ๐ŸŸข 91 ๐Ÿ”—
/en/blog ๐ŸŸข 99 ๐ŸŸข 100 ๐ŸŸข 96 ๐ŸŸข 92 ๐Ÿ”—
github-actions[bot] commented 2 weeks ago

Unit Test Coverage Report

Lines Statements Branches Functions
Coverage: 92%
90.67% (593/654) 76.08% (175/230) 94.57% (122/129)

Unit Test Report

Tests Skipped Failures Errors Time
131 0 :zzz: 0 :x: 0 :fire: 5.244s :stopwatch: