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] e2e-test adaptersv2 always failed on runresources step #628

Closed
Aisuko opened this issue Oct 2, 2023 · 4 comments
Closed

[CI] e2e-test adaptersv2 always failed on runresources step #628

Aisuko opened this issue Oct 2, 2023 · 4 comments
Labels
area/ci Continuous integration | Build and release area/tests Testing / quality assurance issue/stale Issue has not had any activity for an extended period of time

Comments

@Aisuko
Copy link
Member

Aisuko commented Oct 2, 2023

Current Behavior

https://github.com/meshery/meshery-istio/actions/workflows/e2etests.yml

Here is the code https://github.com/meshery/meshery/blob/adf27cfc8f1a9c6d02e1cc0351c66757a8bcab3c/.github/workflows/test_adaptersv2.yaml#L262-L272

There is lots of the Shell script to check the resources are already exist or not. And update the existatus. However, the existatus is always 1, and it means the resources are always failed to start to run.

Run if [ "$exitstatus" -eq 1 ];then
  if [ "$exitstatus" -eq 1 ];then
      exit 1
  fi
  shell: /usr/bin/bash -e {0}
  env:
    MINIKUBE_HOME: /home/runner/work/_temp
    exitstatus: 1
Error: Process completed with exit code 1.

Desired Behavior

The runresources step should be more reliable

Implementation

Acceptance Tests


Contributor Guides and Resources

@Aisuko Aisuko added area/ci Continuous integration | Build and release area/tests Testing / quality assurance labels Oct 2, 2023
@Aisuko
Copy link
Member Author

Aisuko commented Oct 10, 2023

@yash37158
Copy link
Member

Hey @Aisuko, to address the reliability issue and ensure that it is correctly handled we can handle the resource status check. by assuming that we want to check the status of multiple resources and mark the workflow as failed if any critical resource fails while still allowing the workflow to continue in other cases.

This approach should make our workflow more reliable and better handle resource status checks while allowing us to continue with the workflow in cases where some non-critical resources might not be in the "Running" state.

Copy link

stale bot commented Nov 30, 2023

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the issue/stale Issue has not had any activity for an extended period of time label Nov 30, 2023
Copy link

stale bot commented Dec 9, 2023

This issue is being automatically closed due to inactivity. However, you may choose to reopen this issue.

@stale stale bot closed this as completed Dec 9, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/ci Continuous integration | Build and release area/tests Testing / quality assurance issue/stale Issue has not had any activity for an extended period of time
Projects
None yet
Development

No branches or pull requests

2 participants