Abstract: In some examples, test relevancy prediction for code changes may include ascertaining files for a commit for a build, and for each test of a plurality of tests, determining a score based on a weight assigned to a file of the ascertained files. Test relevancy prediction for code changes may further include ordering each test of the plurality of tests according to the determined score, and identifying, based on the ordering of each test of the plurality of tests, tests from the plurality of tests for which the score exceeds a specified threshold. The identified tests may represent tests that are to be applied to the build.

Abstract: Techniques to create and use cluster models to predict build failures are provided. In one aspect, clusters in a set of builds may be identified. The identified clusters may be used to create a model. The model may be used to predict causes of build failures. In another aspect, a failed build may be identified. A clustering model may be retrieved. A cause of problems with the failed build may be predicted using the clustering model.

Abstract: Application management based on data correlations is disclosed. One example is a system including a data processor, a data element generator, a matrix generator, a data analysis module, a performance module, and a load test manager. The data processor accesses test data based on an application under load testing. The data element generator generates a plurality of transactional data elements based on the test data, each data element comprising at least three data components. The matrix generator generates a covariance matrix based on the data components. The data analysis module determines an eigenvector associated with the covariance matrix, and identifies a correlation between a sub-plurality of the at least three data components based on coefficients of the eigenvector. The performance module determines, based on the correlation, performance metrics for the application under load testing. The load test manager manages, based on the performance metrics, the application under load testing.

Abstract: Examples disclosed herein relate, among other things, to determining a trend correlation. In one aspect, a method is disclosed. The method may include, for example, receiving a first data set associated with a first parameter of an electronic device and a second data set associated with a second parameter of the electronic device. The method may also include generating a first trend set based on the first data set, and generating a second trend set based on the second data set. The method may further include detecting, based on the first trend set and the second trend set, a trend correlation between the first parameter of the electronic device and the second parameter of the electronic device, and providing for display correlation information describing the trend correlation.

Abstract: A technique includes obtaining code coverage information related to lines of code. The code coverage information indicates how the lines of code are covered by a plurality of tests. The technique includes generating a two-way mapping based on the code coverage information. The two-way mapping includes a first mapping that maps a particular test in the plurality of tests to at least one line in the lines of code, which is covered by the particular test; and a second mapping that maps a particular line of code in the lines of code to at least one test in the plurality of tests, which covers the particular line of code.

Abstract: In some examples, test relevancy prediction for code changes may include ascertaining files for a commit for a build, and for each test of a plurality of tests, determining a score based on a weight assigned to a file of the ascertained files. Test relevancy prediction for code changes may further include ordering each test of the plurality of tests according to the determined score, and identifying, based on the ordering of each test of the plurality of tests, tests from the plurality of tests for which the score exceeds a specified threshold. The identified tests may represent tests that are to be applied to the build.

Abstract: Techniques for identifying a build commit that caused a test failure are provided. A build which includes a failed test may be identified. For each commit in the build a weighting factor may be calculated for files that have been previously associated with the failed test. The weighting factor may be based on the number of times the file has been associated with the failed test and the total number of tests. A weighting factor may also be calculated for files that have not been previously associated with the failed test based on the number of times the file appears with other files that are associated with the failed test. The weighting factors may be added to create a score for the commit. The scores for the commits in the build may be ordered. The higher the score, the more likely the commit was the cause of the failed test.

Abstract: Techniques to create and use cluster models to predict build failures are provided. In one aspect, clusters in a set of builds may be identified. The identified clusters may be used to create a model. The model may be used to predict causes of build failures. In another aspect, a failed build may be identified. A clustering model may be retrieved. A cause of problems with the failed build may be predicted using the clustering model.

Abstract: Techniques for identifying a build commit that caused a test failure are provided. A build which includes a failed test may be identified. For each commit in the build a weighting factor may be calculated for files that have been previously associated with the failed test. The weighting factor may be based on the number of times the file has been associated with the failed test and the total number of tests. A weighting factor may also be calculated for files that have not been previously associated with the failed test based on the number of times the file appears with other files that are associated with the failed test. The weighting factors may be added to create a score for the commit. The scores for the commits in the build may be ordered. The higher the score, the more likely the commit was the cause of the failed test.

Abstract: Examples relate to providing distributed compilation of statically typed languages. In some examples, first order dependencies of a target module are identified, where each of the first order dependencies is associated with one of a number of dependent modules. Next, each first order dependency of is traversed to remove code references from source code of a corresponding module of the plurality of dependent modules, where each of the code references refers to a type defined in an indirect dependency of the target module, and compile the source code of the corresponding module to generate a module stub of a number of module stubs. At this stage, source code of the target module is compiled using the module stubs to generate a target program.

Abstract: Examples disclosed herein relate, among other things, to determining a trend correlation. In one aspect, a method is disclosed. The method may include, for example, receiving a first data set associated with a first parameter of an electronic device and a second data set associated with a second parameter of the electronic device. The method may also include generating a first trend set based on the first data set, and generating a second trend set based on the second data set. The method may further include detecting, based on the first trend set and the second trend set, a trend correlation between the first parameter of the electronic device and the second parameter of the electronic device, and providing for display correlation information describing the trend correlation.

Abstract: Examples disclosed herein relate to providing code coverage information. The examples enable obtaining code coverage information related to lines of code. The code coverage information may indicate how the lines of code are covered by a plurality of tests. The examples further enable generating a two-way mapping based on the code coverage information. The two-way mapping may comprise a first mapping that maps a particular test in the plurality of tests to at least one line in the lines of code that is covered by the particular test and a second mapping that maps a particular line of code in the lines of code to at least one test in the plurality of tests that covers the particular line of code.

Abstract: Examples disclosed herein relate to providing code change job sets of different sizes to validators. Examples include placing a plurality of jobs in a queue, each job including at least one code change requested to be committed to shared code. Examples further include providing job sets of different sizes to a plurality of validators, each of the job sets comprising a consecutive group of one or more of the jobs in the queue at a given time and beginning with the job at the front of the queue at the given time.

Abstract: Application management based on data correlations is disclosed. One example is a system including a data processor, a data element generator, a matrix generator, a data analysis module, a performance module, and a load test manager. The data processor accesses test data based on an application under load testing. The data element generator generates a plurality of transactional data elements based on the test data, each data element comprising at least three data components. The matrix generator generates a covariance matrix based on the data components. The data analysis module determines an eigenvector associated with the covariance matrix, and identifies a correlation between a sub-plurality of the at least three data components based on coefficients of the eigenvector. The performance module determines, based on the correlation, performance metrics for the application under load testing. The load test manager manages, based on the performance metrics, the application under load testing.

Abstract: Examples relate to providing distributed compilation of statically typed languages. In some examples, first order dependencies of a target module are identified, where each of the first order dependencies is associated with one of a number of dependent modules. Next, each first order dependency of is traversed to remove code references from source code of a corresponding module of the plurality of dependent modules, where each of the code references refers to a type defined in an indirect dependency of the target module, and compile the source code of the corresponding module to generate a module stub of a number of module stubs. At this stage, source code of the target module is compiled using the module stubs to generate a target program.

Abstract: Examples disclosed herein relate to providing code change job sets of different sizes to validators. Examples include placing a plurality of jobs in a queue, each job including at least one code change requested to be committed to shared code. Examples further include providing job sets of different sizes to a plurality of validators, each of the job sets comprising a consecutive group of one or more of the jobs in the queue at a given time and beginning with the job at the front of the queue at the given time.