-
Notifications
You must be signed in to change notification settings - Fork 115
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
Add remote cypress orchestrator integration with integtest script #988
Add remote cypress orchestrator integration with integtest script #988
Conversation
Can we have a demo log or something that we can take a look that can tell us how will the feature be like in the future? |
Certainly! Here is the link to my forked repository, The |
integtest.sh
Outdated
os_url=$(echo "$component" | jq -r '.["opensearch"]') | ||
osd_url=$(echo "$component" | jq -r '.["opensearch-dashboards"]') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What about using the
https://artifacts.opensearch.org/releases/bundle/opensearch/{version_from_manifest}/opensearch-{version_from_manifest}-linux-x64.tar.gz
https://artifacts.opensearch.org/releases/bundle/opensearch-dashboards/{version_from_manifest}/opensearch-dashboards-{version_from_manifest}-linux-x64.tar.gz
as fallbacks of os_url and osd_url?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure! I think OS and OSD url could be other platform/distribution combination as well in addition to linux-x64.tar. But I think we can default to linux-x64.tar when we don't have one defined in manifest. Updated in the latest revision.
remote_cypress_manifest.json
Outdated
"schema-version": "1.0", | ||
"build": { | ||
"name": "OpenSearch Dashboards Functional Test", | ||
"version": "2.12.0" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On main the version should be 3.0.0 I think.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's right. Updated.
remote_cypress_manifest.json
Outdated
"workflow-name": "", | ||
"ref": "", | ||
"opensearch": "test", | ||
"opensearch-dashboards": "test", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As this is an open PR, can we modify these dummy configs to valid ones?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes for main I have added linux-x64 artifact for now. Release team can choose to update component manifest json for other artifact distribution as needed.
integtest.sh
Outdated
done | ||
|
||
# Wait for all processes to finish | ||
wait "${all_process_pids[@]}" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we make remote cypress tasks and FTRepo test task parallel and wait for both to finish? Or I think FTRepo's task will wait for a long time to start.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We wanted to introduce this feature silently integrating in the background of existing integtest script runner for the first iteration to observe the orchestrator behavior. By keeping FTRepo test task run in the foreground after wait, we are not changing the behavior in terms of response code of the integtest script completion. We can make it run in background parallel to other remote cypress tasks, when we are ready to read the response codes from all the tasks integrated and send to integtest script caller (infra team jenkins job).
I agree there will be delay in the start of the FTRepo task but this will help in to ensure better control, immediate visibility into the results, and simplified error handling. This approach aligns with our current requirements and allows us to seamlessly integrate the remote test results into subsequent processes. Let me know if you have other thoughts.
Found this issue: opensearch-project/OpenSearch-Dashboards#5392 |
"version": "2.12.0" | ||
}, | ||
"ci": { | ||
"image": { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Q: how will this image
be used?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This manifest value is optional for now and serves to specify a container image where tests are run , as required by the Orchestrator caller (release workflow). It becomes relevant when we aim to ensure not only the execution of tests on specific version/artifacts but also the use of a specific image configured by the release team. The Orchestrator passes this information to the remote Cypress workflows running in the components/plugins, allowing them to align their GitHub workflows with the image provided by the Orchestrator. While not mandatory, it provides added flexibility to the Orchestrator, allowing it to dictate the container image if/when necessary.
remoteCypress.sh
Outdated
# Check if required arguments are provided | ||
if [[ -n "$REPO" && -n "$WORKFLOW_NAME" && -n "$OS_URL" && -n "$OSD_URL" && -n "$BRANCH_REF" ]]; then | ||
# Accessing the secret as an environment variable using Github actions while invoking this script | ||
GITHUB_TOKEN=$GITHUB_SECRET_TOKEN |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is GITHUB_SECRET_TOKEN
a newly added env var or existing one? Which party is maintaining it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes GITHUB_SECRET_TOKEN
is newly added env variable part of the github workflow - https://github.com/opensearch-project/opensearch-dashboards-functional-test/blob/main/.github/workflows/remote-cypress-workflow.yml#L33 but the token used is existing one within the team's repo used by other github workflows such as delete workflow
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see, is there cases that this script is run outside of github workflow where GITHUB_TOKEN
is not set?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Currently, this will be run as part of integtest
script. Along with that one can manually trigger the remoteCypress script using dispatch event. When integtest
script is triggered as part of jenkins job from infra team, Github token is already set in Jenkins environment which is accessed within this script when run in the jenkins environment.
d96118f
to
dd3511f
Compare
integtest.sh
Outdated
source remoteCypress.sh -r "$repo" -w "$workflow_name" -o "$os_url" -d "$osd_url" -b "$branch_ref" & | ||
bg_process_pid=$! | ||
echo "PID for the repo $repo is : $bg_process_pid" | ||
all_process_pids+=($bg_process_pid) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i think it might be worth to consider using pid files https://github.com/opensearch-project/OpenSearch-Dashboards/blob/main/config/opensearch_dashboards.yml#L122
i didn't realize this logic existed but has long as the file is created we can reference the process id file instead of it in memory
integtest.sh
Outdated
REMOTE_MANIFEST_FILE="remote_cypress_manifest.json" | ||
|
||
# Parse the JSON file using jq and iterate over the components array | ||
components=$(jq -c '.components[]' "$REMOTE_MANIFEST_FILE") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: for readability it might be helpful to have a helper function for this and perhaps it returns back a tuple with the required information
integtest.sh
Outdated
branch_ref=$(echo "$component" | jq -r '.["ref"]') | ||
|
||
# Set default values if the opensearch and opensearch-dashboards are not set in the manifest | ||
os_url=${os_url:-https://artifacts.opensearch.org/releases/bundle/opensearch/$release_version/opensearch-$release_version-linux-x64.tar.gz} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
linux-x64
. i think it should get the operating system of the runner and arch
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've adjusted the manifest to get operating system/arch and constructing the url while parsing the manifest with the base url being https://ci.opensearch.org/ci/dbc/distribution-build/
.
integtest.sh
Outdated
echo "branch_ref: $branch_ref" | ||
|
||
# Call the function for each component | ||
run_remote_cypress "$repo" "$workflow_name" "$os_url" "$osd_url" "$branch_ref" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i think we should add a flag or env variable that enables us to conditional run the run remote cypress tests are not. since this repo is now being locked as well to commits a new build will have to be made if there are any issues. so it pre-planning a feature flag could be a fallback to disabling this if it causes issues.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I referenced the developer guide doc about setting up flag for experimental features and its tests. As my feature is not actually running cypress tests but instead running orchestrator workflows, I've introduced a simple boolean flag as part of integtest.sh
script params defaulting to true
. Build script which triggers integtest.sh
can set the feature flag to true/false as required. Is this the behavior you were expecting or is there some other way to configure this setting in FTRepo?
7b55235
to
cb4644a
Compare
cb4644a
to
51411a8
Compare
Signed-off-by: manasvinibs <[email protected]>
51411a8
to
fdb9bf3
Compare
@kavilla @SuZhou-Joe @ruanyl Can you please review and let me know if there anything else you would like me to address to get this checked in? I'm hoping to get this in for 2.12 and would like to have some time to bake this changes in main and address any issues related to integration. |
"repository": "opensearch-project/OpenSearch-Dashboards", | ||
"workflow-name": "", | ||
"ref": "", | ||
"operating-system": "linux", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
os
done < "$pid_file" | ||
} | ||
|
||
if [[ $REMOTE_CYPRESS_ENABLED = "true" && $ORCHESTRATOR_FEATURE_FLAG = 'true' ]]; then |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
check if env variable for github token if not then don't execute this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure! I have a follow-up PR to add manifest data to this. I'll address this one in that.
…earch-project#988 backports Signed-off-by: Peter Zhu <[email protected]>
…backports and disable windows video recording (#1070) * [2.x] Adding placeholder to keep main/2.x/1.x consistent before #988 backports Signed-off-by: Peter Zhu <[email protected]> * Add more Signed-off-by: Peter Zhu <[email protected]> --------- Signed-off-by: Peter Zhu <[email protected]>
…backports and disable windows video recording (#1070) * [2.x] Adding placeholder to keep main/2.x/1.x consistent before #988 backports Signed-off-by: Peter Zhu <[email protected]> * Add more Signed-off-by: Peter Zhu <[email protected]> --------- Signed-off-by: Peter Zhu <[email protected]> (cherry picked from commit 4add696)
…backports and disable windows video recording (#1070) (#1071) * [2.x] Adding placeholder to keep main/2.x/1.x consistent before #988 backports Signed-off-by: Peter Zhu <[email protected]> * Add more Signed-off-by: Peter Zhu <[email protected]> --------- Signed-off-by: Peter Zhu <[email protected]> (cherry picked from commit 4add696) Co-authored-by: Peter Zhu <[email protected]>
Hi @manasvinibs if you ever want to backport please note that I have add placeholder for We have to disable the remote test settings in build repo due to it failing out production integTest on Jenkins. Thanks. |
The backport to
To backport manually, run these commands in your terminal: # Fetch latest updates from GitHub
git fetch
# Create a new working tree
git worktree add .worktrees/backport-2.x 2.x
# Navigate to the new working tree
cd .worktrees/backport-2.x
# Create a new branch
git switch --create backport/backport-988-to-2.x
# Cherry-pick the merged commit of this pull request and resolve the conflicts
git cherry-pick -x --mainline 1 a844c23837830641a3273778c96179d3c5099bc4
# Push it to GitHub
git push --set-upstream origin backport/backport-988-to-2.x
# Go back to the original working tree
cd ../..
# Delete the working tree
git worktree remove .worktrees/backport-2.x Then, create a pull request where the |
Description
Adding remote cypress workflow orchestrator script integration with existing logic of integtest.sh script. This will keep the current behavior of integtest script as it is when triggered along with silently triggering the remote cypress workflows present in the plugin/components as defined in manifest json file and continue to poll them till its completion.
Changes summary:
Issues Resolved
Follow-up to
#972
#991
Check List
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.