I have 2 tasks in my Release Pipeline in DevOps. One distributes the Android package (Xamarin Forms) to App Center, which is working fine. The second distributes the iOS package (Xamarin Forms), also to App Center, but has stopped working in the last few days.
The error I get now is on the Distribute task is: Unauthorised. Correlation ID: ...http response code: 401
Why am I getting Unauthorised errors for 1 task and not the other, and how to I know who/what isn't authorised?
Sorted. It was the token in the App Center
Related
I have been trying blue green deployment with code deploy, but it throws an error: The following validation error occurred: Target group not attached to the Auto Scaling group (Service: AmazonAutoScaling; Status Code: 400; Error Code: ValidationError; Request ID: cd58091b-fe83-4dcf-b090-18c3b3d2dbbc; Proxy: null)
Though the policy has been applied to create target groups:
codedeploy:GetDeployment
elasticloadbalancing:DescribeTargetGroups
autoscaling:AttachLoadBalancers
autoscaling:AttachLoadBalancerTargetGroups
Does anyone could help me to sort out the issue & what am i missing?
The following is the error i encounter.
error
In our case, we managed to fix it the hard way by contacting AWS support team. Briefly about our app, we run Magento application behind an application load balancer with autoscaling, and the deployment is managed using AWS CodeDeploy on blue/green deployment.
We spent several days figuring out what's going on. Others suggested that there might be issue with IAM permissions, but we didn't touch that for months and deployment has never had any issues.
AWS' rep replied to us and said that in our case, there is a known issue / limitation on AWS Codedeploy that it currently don't support Blue/Green deployments based on ASGs that use Target Tracking scaling policies, because currently they don't attach the Green ASG to the original target group, and this is a requirement when Target Tracking scaling policies is enabled on the autoscaling group.
We then realized that we did some minor changes on our autoscaling groups' dynamic scaling policies that we switched from "CPU utilization"-based metrics to "Request count". Reverting it back to CPU utilization-based metrics solved the issue and we can run the deployment successfully.
Hope it helps as this error seems not to be documented in AWS doc.
I am setting up Integration Broker messaging from HCM 9.2 to FSCM 9.2 using the PERSON_BASIC_FULLSYNC service operation (the delivered process) to sync data from HCM to FSCM. I have activated the service operation, handler, queue, and routing on both sides, however when I run the Full Data Publish process, it runs to No Success with the following error:
Fetching array element 0: index is not in range 1 to 3.
(180,252) EOL_PUBLISH.PUBDTL.GBL.default.190 0-01-01.Step05.OnExecute PCPC:16088 Statement:266
I had initially run this process, and it ran to success, however it did not publish any new data in PS_PERSONAL_DATA in FSCM, so I updated the service operation version in HCM from 'INTERNAL' to 'VERSION_1', as the corresponding service operation in FSCM only had the 'VERSION_1' version available. But after I change the version so they match, and run the process it goes to No Success.
If I set the version of the service operation in HCM back to 'INTERNAL' and run the process, then it is successful but no data gets published in PS_PERSONAL_DATA. Any thoughts on what I should look at?
Sounds like a service op. routing problem. Confirm the routing directions and ensure that any alias' that are set don't cause issues. Service Ops on each side need to be the same.
I've tried two times to deploy an already successfully trained model in Microsoft Custom Translator dashboard (Bleu score: 38.31).
The deploy process ends always with "Deployment Failed" status, not any error message. The model is the first and the only one present in the project.
I have a S1 subscription plan. Has anyone encountered a similar issue?
Thanks
Max
When I run my Espresso tests from Android Studio 2.2.1 using Test Lab for Android I get the following error message:
Exception while triggering a matrix execution. 429 Too Many Requests.
I managed to run several tests on remote devices, but then they start failing with this error message. Firebase console shows nothing.
What might be the issue?
This is the HTTP Status returned when a project that is on the Flame or Spark tier has used too much of its quota.
Projects on the Spark and Flame tier can send up to 10 virtual device tests and 5 physical device tests per day (with each day beginning at midnight PDT). In addition, there is a maximum of 4 tests per test matrix for projects on these plans.
See https://firebase.google.com/pricing/ for more.
I currently trying out Amazon Device Farm and was able to get a dummy app to work.
However, when I tried getting the actual App I want to get working on Amazon device farm, I'm unable to do so. I'm able to upload the .ipa file, and zip up and upload the py.tests/appium tests with their dependencies, however the tests fail.
What I think might be happening is ADF is not recognizing some of the Desired_capabilities to autodismiss the Alerts for Notifications and GPS coordinates.
My setup is very similar to the setup I used with the dummy app in my initial tests. (these worked with amazon device farm)
https://github.com/dlai0001/appium-spike-running-tests-oncloud
Only thing that is really different is I'm using a real production app, where 2 alert windows popup upon launch. In Appium it will cause the test to crash if I don't have the autodismiss or autoaccept alerts enabled in the desired capabilities.
Harness 00:00.0 1295 Info Starting 00001 with device c00e8ab68437161b894395e438ba8935a672bac0
Harness 00:00.0 1295 Info Using test content version 0.1.0
Harness 00:00.1v1295 Info Using image version ami-778b7c17
I work for the Amazon Device Farm team.
It appears that you are relying on desired capabilities to dismiss the alert window. Currently, Device farm has support for a very limited set of desired capabilities namely app name, package name and osversion. These are available to the application without having the user required to set it.
Appium runs with autoAcceptAlerts=true on Device Farm. This should handle the alert windows, if any, unless it is a system pop up which autoAcceptAlert cannot handle. You should check if your tests can handle the alert windows using autoAcceptAlerts=true with Appium pre launch mode locally.
If it can handle it then device farm should behave the same way.
Sometimes it may be the case that the alert window appears before the appium session is established in which case adding a delay can help.
When you test is locally please use Appium version 1.4.16 since this is the version being used on device farm right now.