When a final build is provided by the dev team, before starting my sanity scripts on the app, how can I able to know that the build provided is a release or a beta build
In AndroidStudio one can use DebugBuild Config to check that, but in Appium(using Java) what is the method or parameter I can look for?
Related
Crashlytics could not find the resource file generated by Google Services.You may need to execute the :processGoogleServices Task
i read the solution from this qusetion Crashlytics could not find the resource file generated by Google Services. You may need to execute the :process<Variant>GoogleServices Task
but i didn't succeded to run this command in my unity project
./gradlew :app:processProdReleaseGoogleServices or ./gradlew :app:processDevReleaseGoogleServices
how can i run it?
A tricky bit with the Unity SDK is that because Firebase still supports versions of Unity that predate a total move to gradle (I believe 2019.4 is when Unity switched over entirely, the earliest supported version right now is 2017.4), many Android specific solutions (such as the one you linked) won't function. If you did want to try it, you can select "Export Project" in your build settings -- but I don't think this will help:
It sounds instead like you're missing Plugins/Android/FirebaseApp.androidlib or Plugins/Android/FirebaseCrashlytics.androidlib. These are generated by the Firebase plugins (obviously FirebaseCrashlytics.androidlib is specific to Crashlytics -- you won't see that one otherwise) as part of a processing step to simulate what the Play Services gradle plugin would do in a typical Android application or game.
Some things to try:
Make sure you're on a supported version of Unity (2017.4 or newer -- Firebase does not officially support alphas or betas).
Ensure that you have a valid google-services.json file added and that Crashlytics has been added to your backend (full instructions here to redownload).
Re-add FirebaseCrashlytics and ensure that you leave everything checked.
Ensure that you have the latest Crashlytics plugin (currently 7.1.0). You can download just Crashlytics now from this site, but make sure you don't mix and match versions with other Firebase plugins.
And if none of these work, sometimes small changes in build environments expose unexpected issues. Your best bet will be to file an issue here with everything you've tried.
We use Team City as our CI server and Build Master as our deployment mechanism. I have a project that builds and runs test on teamcity and creates a release-0.0.%build.number%.zip.
How do i instruct Build Master to get the latest release-0.0.%build.number%.zip?
Currently I use Create Build Artifact which collects files from a directory, but this is causing problems for us. I already have the artifact as a .zip and just want to deploy that.
Have you looked at the TeamCity Extensions? The idea that immediately comes to mind is to use the Get TeamCity Artifact action, which has the option to use latest Build or specify a variable. This might be easiser than pulling from disk, too.
If you have a project that builds one project before building the next, but the next needs to know the 'path' of the first build, is it possible to get this?
For example:
Project A has Build Configuration A and Build Configuration B.
Build Configuration B has a dependency on Build Configuration A. From without the Build Configuration B it will need access to the path of Build Configuration A. Is there are a way to obtain this?
Most simple approach would be to define a custom checkout directory in the A and use the same hard-coded value in B.
If you use TeamCity snapshot or artifact dependencies, you can use %dep.btXXX.teamcity.build.checkoutDir% to get checkout directory of the dependency build. However, this will not work in 6.5.0-6.5.5 TeamCity versions, see details and workaround in the issue TW-18715.
However, you should really avoid accessing checkout directory of one build from another. If you need sources of A, you can checkout them in B; if you output of the A's build, then publishing the output as build's artifacts and then using TeamCity artifact dependencies is the way to go. In both cases additionally using TeamCity snapshot dependencies will ensure both builds use the same sources snapshot which is probably what you need.
If you have one agent, and only ever one agent then you could try and use the path from a previous build.
I wouldn't recommend doing this however because if you had two agents, or scaled up in the future to two agents, then it is possible your projects will be built on different agents; this would mean your dependency working directory won't be on the same machine, or it will be outdated as the latest was built elsewhere.
I assume you're after the path of the first build to get its output?
If so, the method we use to share dependencies between projects is to checkin the output from each project into our source control, then every project that requires the output simply has to check them out.
CCNET questions - Here's the scenario:
I've got 10 developers doing local development to a Sitecore installation w/GIT as version control. When done with their feature/fix they push to an integration repository.
I've got CCNET setup for the Sitecore project that points to the remote Integration rep and the local live qa code base. CCNET finds the commits that my developers have made to integration repository and then updates the qa code base repository.
I also have a couple other .Net class lib projects that are managed by CCNET, compiled with their output pointed to the Sitecore bin dir.
The Sitecore installation is merely a result of a build with no compilable aspects. Its a web product with it's own API as well as the ability to integrate custom dll that we create to customize the product.
Questions:
Is CCNET build task required as a condition to execute other activities such as nUnit or robocopy? (the reason I ask this is because a "build" is natively used to compile an app and generate output, whereas, the only reason why we'd want to build is to make sure all dependencies are there and we can jump to unit testing...).
If my developers are NOT pointing to a centralized rep like integration, how would CCNET know where all of their remote GIT repositories are when the config doc only allows one GIT source control section per project?
Per project when I configure the GIT vc specs it asks for the branch that needs to be statically saved to the doc. Does CCNET have the ability to accept different branches dynamically?
There's no need to have an "actual build" in your project - it could consist of any type of tasks inside the tasks element. I have a couple of projects which only copy the files from the repository to an FTP server after deleting some files which shouldn't be published.
I have no experience with GIT but you have a possibility to define multiple source control blocks of any type if you use the multi source control block.
You could use dynamic parameters which allow the user to set their values when triggering the build.
I'm building a Flex/AIR application that connects to a remote server, the URL of which changes depending on the environment (development/production, and possibly others). For now, this URL parameter is hardcoded in my root application MXML file but it means I have to change it everytime I build my app for a different environment.
Is there a way to externalize such a parameter so that when Flash Builder automatically builds my app (in development mode), it uses the development URL (http://localhost...) and when Flash Builder exports a release build, it uses the production URL (http://www.mycompany.com/myapp)?
Flex compiler supports something called Conditional compilation, you an read about it here: link. The problem is that it still doesn't give you an way to check if you're exporting a release build or building for debug. Probably the simplest way to achieve that is to use ANT for compilation of the release build and use the conditional compilation from there.