… causing any mismatched misconfiguration in ci (test pass locally)

… file

…ge cases

…ge cases and many to one targets

…ent specific to the test case

…ia/oppia-android into code_coverage_many_to_one_targets

…verageReporter, merge updates

… its not a flake

…emoving it to see if that is actually causing the issues (may be with idle times)

… most importantly helps with max idle run time issues

…ia/oppia-android into code_coverage_many_to_one_targets

…m/oppia/oppia-android into code_coverage_list_of_files

…o code_coverage_fix_edge_cases

…ia/oppia-android into code_coverage_many_to_one_targets

…test cases for sets of success, failure and anomaly cases

… to note with 12 the run completed in just 200 seconds

…4 and 6 seems like a middle ground

…es that will later be provided as arg for RunCoverage script run

…nged files buckets

… all file retrieval process since the output of ls-files is not desirable

Note: This is a blind copy paste of the unit test implementation and this needs a lot of refining to get review ready. To self: 1. The coverages should only run after all tests have passed 2. Not sure if caching would be needed here or its necessary to understand caching here 3. Same with Oppia Build Tests, since those will require targets not sure if we will need to have an implementation for again mapping them to tests or can we run coverages directly in run coverage job, 4. The output files could possibly be moved here as paths or make sure to use the same output path here (better to move here to not cause any confusion) 5. The final .md report and the status check results should be reflected here to properly set pass and fail cases and to handle uploading of comments

Additionally it is noted that the files that do not have test files were added to the anomaly cases, I think it would be more appropriate to have the coverage check status set to false over there and notify the developers since there was a file that doesn't have test the coverage fails alert. Though we assume that script check checks these cases and proceed it would be better to have it as a case within the script itself to make it not dependant on other scripts or checks.

…robably Build Oppia Tests should be the fix

…rage check status fail

…g and pushing them

…t of changed files provided

Since the code coverages take a long time, it should be possible that the builds are taking the most times which cause process didn't finish within intended time errors. So may be having the build oppia tests beforehand should help with this, but since we use just the changed files for the input to our run coverage scripts we will need this extra utility (or if possible lets try to move it with something else if possible retrieve changed files.kt) to handle the mapping of changed files to their respective targets to feed to build them

…eve changed files test targets

…ine dispatcher

… with large tests that need to be handled first

…ge to make use of the same size and shard count values for coverages

Testing it with MathModelTest does run coverage in shards while adding large and shard counts, but they do produce multiple shard coverage.dat files which on viewing seem to have entire coverage data but I just want to make sure that they are not produced as separate results, if they do then that will be a mess and we will need to figure out a way to combine all those data (would be better if bazel has that functionality (I think they do). Also testing with RunCoverageTests is taking over half an hour  with sharding so ci should be a better place to view those results.

…o interupt with the coverage output path

…t to see if that can handle the coverage cases

Also the compute affected tests test do pass with shards set and coverage runs with bazel test --collect-coverage but the percentage is yet to be cross checked

…ts before running

… referenced before assignment

… capturing with sharding

RunCoverage: 70.16%, ComputeAffectedTestsTest: 77.27%, BazelClient: 87.04%

…ercentages especially with RunCoverageTest

RunCoverage: 70.16%, ComputeAffectedTestsTest: 77.27%, BazelClie

This doesn't change any logic of the coverage retrieval but just prints the data to observe the actual collective data results. Major concern with this approach is that the coverage results shouldn't be overriden by the other, which will be confirmed through this and also by running with a bulk of reports later

…rt storage path

…ages

Last 2 times outputted the same result and no changes were detected but I will have to check the runs with more test shards running atleast a 10 times to see if this is accurate so probably a 10 more re runs will be coming after this

…ly its not gonna do anything as its only with caching

…ection in the workflow

…ries to build oppia tests

…st to trigger test runs for coverage

…iguration and tests that don't have shard configuration

The reason for this is -with tests that have shard configuration, to use the same shards we need to use the bazel test --collect code coverage flag to run them with the same parallelization but the downside is they also provide the coverage results in separate shards which could easily turn into a misrepresentation if the coverage.dat file has missing information since they only represent data of one shard. This was noticed with RunCoverageTest where on alternate runs in ci it represented percentages of 50% and 70% with the exact same test data. To overcome this we need to combine these coverages into one. While bazel does provide --combined report flag, it doesnot provide the ability to provide a desired path. Which is again a next downside. So far the provided combine report flag saves the report to the _coverage/_coverage_report.dat file but but but the catch is, it is the same dir for all the coverage (test) runs. Which means that while running asynchronously if a report is overriden there is a change of discrepency in the data at times. This might be a rare case but it is definitely not fool proof atleast to the extend I can think of. -And also this method of collect coverage flag might not even be required for non sharded tests, since this might introduce extra effort and even overriden reports too as now they too will use the same common report folder. So now there are 2 ways of executing coverage 1. with bazel coverage for non sharded tests 2. with bazel test --collect_code_coverage for sharded tests.

…--collect_code_coverage output to view shard coverage data

This will be later removed. Using lcov's merge mechanism combines every data even that are not relavant to the source file making it un reliable, another option would be to manually merge them which would again turn complicated when dealing with branch and function data on scale

… are completed

…o code_coverage_many_to_one_targets

…get implementation

…a/oppia-android into code_coverage_ci_workflow

…hecks only after the Unit Test checks have passed

Native workflow_run, workflow_call, local action call, needs, reusable workflows don't seem to satisfy the desired requirement

…actions need approval

…s commit

…into one since they majorly duplicate many implementations

…d files utility to save buckets, files and targets values

…trieve changed files test targets utility

Yet to add cases for retrieving and checking test targets

Might be a flaky test

Probably require a lot of iterations to check all passes an clear up the centralized protos execution. Things to do 1. Add error messages to be included in the failed coverage report proto to provide more info on the fail case, 2. Have one centralized proto generation to handle md generation (flexible for both local and ci and with distinction in creation based on md and html (need to figure out), 3. Update to have a sequential flow, 4. Update tests as most error cases are removed