I've recorded a simple login Robo Test to be executed by App Crawler. I've provided the script to app crawler, and I see in the logs where it loads it, and tries to execute it. However, it always fails at the first action by saying it cannot find the Element.
I see on the screen where it tries to start executing the actions, but it immediately says it executed zero actions and then goes into the pre-canned scripts.
The most common reason for such cases is that your app looks/behaves differently during recording and replaying phases. In particular:
Your app might be built with one app package id for debug APK (which is used for Roboscript recording) and a different one for release APK (which you use to perform a Robo crawl with the recorded Roboscript).
Your app might show different dialogs or have a somewhat different screen setup during recording and replaying phases (e.g., due to different environments and/or versions).
You either need to ensure a consistent app look/behavior or modify the recorded Roboscript to remove attributes that are different during recording and replaying phases (e.g., resource ids that use app package id as prefix or contextDescriptors for parent elements).
Related
I'm trying to setup the CI/CD setup of a mono repository using Google Cloud Build. We have a single Cloud Build trigger that starts a build on a new commit, it does some general steps and then then starts a build for every (micro)service in the mono repository using gcloud build submit.
This however means that if 4 or 5 people are push code to the repository roughly at the same time we can have around 50-70 concurrent builds running in cloud build. Which in itself isn't an issue for us. The only issues is that when this happens the following errors will popup:
{
“code”: 429,
“message”: “Quota exceeded for quota metric ‘Build and Operation Get requests’ and limit ‘Build and Operation Get requests per minute’ of service ‘cloudbuild.googleapis.com’ for consumer ‘project_number:<PROJECT_NUMBER>’.“,
“status”: “RESOURCE_EXHAUSTED”,
“details”: [{
“#type”: “type.googleapis.com/google.rpc.ErrorInfo”,
“reason”: “RATE_LIMIT_EXCEEDED”,
“domain”: “googleapis.com”,
“metadata”: {
“service”: “cloudbuild.googleapis.com”,
“consumer”: “projects/<PROJECT_NUMBER>”,
“quota_limit”: “GetRequestsPerMinutePerProject”,
“quota_metric”: “cloudbuild.googleapis.com/get_requests”
}
}]
}
In other words: We are running into quota limits. The quota only allows us to only make 900 operational requests per minute.
We already tried switching to private pools in the hope that the above quota limit was only there for when you don't use private pools, but this unfortunately still makes us hit the quota.
Now, I am trying to find out if I can decrease the amount of these operational requests.
A possible solution might be related to how I am using gcloud build submit. When you run gcloud build submit, it starts a new build, waits for the build to finish, and shows the output of the build. To achieve this, I presume that gcloud is making requests every few seconds to find out what the status of the build is. I suspect that these 'status' requests are why my Cloud Build quota limit is reached. Which is why I'm trying to see how I can lower the amount of these requests per minute.
One option is to simple decrease the amount of builds running in parallel, which is unfortunately not an option in my situation. If I execute them sequentially it simply takes more time than acceptable in my situation.
Another option would be to increase the time in between such 'status' requests. However, on this page I did unfortunately not find a CLI flag to alter this.
Note: I did find the --async flag, however that does NOT help me, since I still want the process to wait until the build has succeeded. And I also did find the --supress-logs, which also does NOT help me, since these requests presumably don't interact with Cloud Build but with the GCS bucket where the logs are stored.
The only option left that I can think off, is that I can start my builds with the --async flag and then manually request whether the build has succeeded using a longer interval. However I do feel like that is a lot of manual work that, for which I need to write some bash scripts that need to be maintained. This preferably isn't a path I would like to take unless really necessary.
Does anyone know of another way of achieving this?
If 4 or 5 people are push code to the repository
This shouldn't happen. The reason it shouldn't happen is because you should use the "push" trigger on the main branch, not on a development branch.
What do I mean by this?
I mean that building should occur on the main branch, which would correspond to joined effort of those five users and a responsible party in charge of unifying their changes.
So, really, your users should be pushing to the development branch, and pushes to main should be reserved for things that need to be built.
How can we work around this if we're only allowed one branch or are required to have updates visible on one branch?
My recommendation would be to use the tag filter, specifically filter the pushes by tag, as mentioned in the documentation. That way only the pushes person in charge of merging the changes will be built (assuming that this person pushes to the tag you've set)
TL;DR
Don't create push triggers for Cloud Build on a branch multiple people are working on. Either create it with a tag filter or have seperate development and main branches (people work on dev, builds are only made from pushes to main)
I have test suite where in one of the spec the 5th test-case is dependent on 3rd test-case. While the case is run locally via cypress runner - I do not see any issue in order of running.
But while case is running in CI - I'm seeing 5th is failing randomly [verified that no script errors] & upon analysis I notice that certain data records which are created in 3rd case are not returned for 5th case & hence its failing.
Is there a way to order tests within a spec in Cypress?
Unfortunately it is not possible to run tests within the same spec file in specific order in Cypress currently.
Cypress is basically just scheduling events to happen, with no additional control beyond that, so there is no way to guarantee tests will run in a specific order.
I have a bunch of HTML5 canvas tests in my library which I run via Karma and Jasmine. If I detect differences in my tests I show the canvas DOM elements with my generated image output and a diff on the browser page. But when I run my tests in Chrome Headless and/or on my CI environment I have no way of checking the test results in case they fail. And that's currently the issue I'm facing: when I run the tests with a UI, they are green, if I run them in Chrome Headless they fail but I have no chance of checking my visual output.
As solution I'd like to write my generated images to disk. On local tests I can then check this folder what happened an on CI I can publish the result images as artifacts. But here comes the point: Karma and Jasmine seem to have no proper mechanism in place for this task. Also I could not find any plugin tackling this challenge of properly accessing the local file-system from your tests.
A tricky aspect is also that I cannot use promise (async/await) operations at the place where I want to save files. I am within a Jasmine CustomMatcher which does not have promise support I could try rewriting my tests again to handle the error reporting to Jasmine.
My attempts so far:
I started with a custom Karma reporter listening to browser logs and potentially use this as channel to hand over the image bytes to Node for writing to disk. But this additional plugin registration messed with my overall Karma configuration. Karma and Rollup were not working anymore once I registered my custom reporter and I never found out if such large byte amounts can be even transferred via this channel.
Then I started with an API via karma-express-http-server where I "upload" the files to be saved. But I stopped half way as such a simple task seem to require again a bunch of libs and custom implementation to get a simple file upload running (karma-express-http-server, multer). Also I need to rely on synchronous Ajax calls here which is not really future proof.
The Native File System API heavily relies on Promises so I cannot use it.
There must be a simpler way of just writing a file as part of your tests to disk while when using Karma and Jasmine.
In my application I get rss feed from a website and than compare it with previously saved feed in isolated storage and show the updated feed. I want to update live tile with the updated feed items count, even when the app is not running. Kindly gave me guidelines for this.
You can use a background agent scheduler task. Depending on how resource intensive your call is, you can opt to use a Periodic tasks.
see periodic tasks here
See an example of how to implement it here
you have to note that the earliest a periodic task would run in wp7 is every 30 minutes. it is also subject to available resources on the device, hence it might not always run when you want it too.
I have run into a situation where I need to open a newly created quote at the end of a workflow. I have a feeling this is going to require me to create a a very simple custom workflow that uses "window.open", but I would like to avoid this if anyone has a better idea.
So I need to open a newly created quote as soon as it is created in a workflow. Anyone have any good ideas on how to do this?
Workflows are asynchronous; they run on the server (as opposed to the client) and do not run in realtime. eg a workflow that is triggered by creation of a record will run on the server sometime after the record is created (depending on system load etc - it could be a second or two, or could be half an hour later. If you have stopped the CRM Async service on the server, they might well never run.)
Because they run on the server the user has no interaction with them. As a result you can't open a window, as there's no user involved to open a window for...
What you probably want to do is make use of Dialogs (introduced in CRM 2011). You won't be able to use window.open() but as long as you've got a recent update rollup installed on the server you can present the user with a hyperlink to most CRM records.
Setup of Dialogs is much the same as Workflows, and they use the same mechanics under the hood. The difference is that they're syncronous (i.e. run in real-time) and they are client-side. There's some detail on Technet: http://technet.microsoft.com/en-us/library/gg334463.aspx