bitrise-steplib / steps-virtual-device-testing-for-android

MIT License
22 stars 23 forks source link

Failed to upload test assets, error: failed to start test: 403, error: {"error":"Unauthorized request"} #73

Closed DanielJette closed 3 years ago

DanielJette commented 3 years ago

Troubleshooting

Useful information

Issue description

All our Virtual Device Testing for Android steps are failing with 403:

Failed to upload test assets, error: failed to start test: 403, error: {"error":"Unauthorized request"}

Uploading app and test files
App path (/bitrise/deploy/Neo.internal-debug-2021.8.apk), is bundle: false
Assets requested: {isBundle:false testApp:<nil> Apk:{UploadURL: GcsPath: Filename:Neo.internal-debug-2021.8.apk} Aab:{UploadURL: GcsPath: Filename:} TestApk:{UploadURL: GcsPath: Filename:app-internal-debug-androidTest.apk} RoboScript:{UploadURL: GcsPath: Filename:} ObbFiles:[]}
Failed to upload test assets, error: failed to start test: 403, error: {"error":"Unauthorized request"}

Bitrise info

+------------------------------------------------------------------------------+

| (4) virtual-device-testing-for-android@1                                     |
+------------------------------------------------------------------------------+
| id: virtual-device-testing-for-android                                       |
| version: 1.1.4                                                               |
| collection: https://github.com/bitrise-io/bitrise-steplib.git                |
| toolkit: go                                                                  |
| time: 2021-05-12T15:16:32Z                                                   |
+------------------------------------------------------------------------------+
|                                                                              |
Configs:
- AppPath: /bitrise/deploy/Neo.internal-debug-2021.8.apk
- TestTimeout: 3000.000000
- FlakyTestAttempts: 0
- DownloadTestResults: true
- DirectoriesToPull: /storage/emulated/0/Android/data/com.neofinancial.neo.debug/files/testify_images/
- AutoGoogleLogin: false
- EnvironmentVariables: TESTIFY_USE_SDCARD=true
useSdCard=true
- ObbFilesList: 
- TestDevices:
---
Model    API Level   Locale   Orientation   
Pixel2   29          en_US    portrait      
---
- TestType: robo
- RoboInitialActivity: 
- RoboScenarioFile: 
- RoboDirectives: 
- RoboMaxDepth: 
- RoboMaxSteps: 
Uploading app and test files
App path (/bitrise/deploy/Neo.internal-debug-2021.8.apk), is bundle: false
Assets requested: {isBundle:false testApp: Apk:{UploadURL: GcsPath: Filename:Neo.internal-debug-2021.8.apk} Aab:{UploadURL: GcsPath: Filename:} TestApk:{UploadURL: GcsPath: Filename:} RoboScript:{UploadURL: GcsPath: Filename:} ObbFiles:[]}
Failed to upload test assets, error: failed to start test: 403, error: {"error":"Unauthorized request"}
|                                                                              |
+---+---------------------------------------------------------------+----------+
| x | virtual-device-testing-for-android@1 (exit code: 1)           | 9.46 sec |
+---+---------------------------------------------------------------+----------+
| Issue tracker: ...se-steplib/steps-virtual-device-testing-for-android/issues |
| Source: ...thub.com/bitrise-steplib/steps-virtual-device-testing-for-android |
+---+---------------------------------------------------------------+----------+
  

Steps to reproduce

  1. ...
  2. ...
ofalvai commented 3 years ago

Hey @DanielJette, thanks for the report! We have found the root cause and deployed the fix, it should be working now. Please try re-running the failed build.

DanielJette commented 3 years ago

Hi @ofalvai Unfortunately the same error appears on a re-run triggered on 2021.05.12 @ 13:15

https://app.bitrise.io/build/aec9fb3795aac4fe#?tab=log

+------------------------------------------------------------------------------+

| (3) Testify UI Testing                                                       |
+------------------------------------------------------------------------------+
| id: virtual-device-testing-for-android                                       |
| version: 1.1.4                                                               |
| collection: https://github.com/bitrise-io/bitrise-steplib.git                |
| toolkit: go                                                                  |
| time: 2021-05-12T17:29:37Z                                                   |
+------------------------------------------------------------------------------+
|                                                                              |
Configs:
- AppPath: /bitrise/deploy/Neo.internal-debug-2021.8.apk
- TestTimeout: 3000.000000
- FlakyTestAttempts: 3
- DownloadTestResults: true
- DirectoriesToPull: /storage/emulated/0/Android/data/com.neofinancial.neo.debug/files/testify_images/
- AutoGoogleLogin: false
- EnvironmentVariables: TESTIFY_USE_SDCARD=true
useSdCard=true
- ObbFilesList: 
- TestDevices:
---
Model    API Level   Locale   Orientation   
Pixel2   29          en_US    portrait      
---
- TestType: instrumentation
- TestApkPath: /bitrise/deploy/app-internal-debug-androidTest.apk
- InstTestPackageID: 
- InstTestRunnerClass: 
- InstTestTargets: 
- UseOrchestrator: false
Uploading app and test files
App path (/bitrise/deploy/Neo.internal-debug-2021.8.apk), is bundle: false
Assets requested: {isBundle:false testApp:<nil> Apk:{UploadURL: GcsPath: Filename:Neo.internal-debug-2021.8.apk} Aab:{UploadURL: GcsPath: Filename:} TestApk:{UploadURL: GcsPath: Filename:app-internal-debug-androidTest.apk} RoboScript:{UploadURL: GcsPath: Filename:} ObbFiles:[]}
Failed to upload test assets, error: failed to start test: 403, error: {"error":"Unauthorized request"}
ofalvai commented 3 years ago

Hey @DanielJette, we looked at your project specifically and made the required fix. Please let us know if it's working now.

DanielJette commented 3 years ago

Hello @ofalvai . Thank you very much for your attention to this matter. I can confirm that all our workflows are now running correctly. I appreciate your help with this.

Is there anything regarding this fix that we could have managed on our own? If something similar were to reoccur, what actions should we take?

ofalvai commented 3 years ago

@DanielJette it was an authentication issue on our side, affecting a certain group of users. We fixed it in an internal system, it was not something a user could have fixed in their workflows. Apologies for the inconvenience caused, and thank you once again for reporting the failure.