Abstract: Techniques for (i) using contextual information associated with an exposed credential to identify a resource that could be accessed using the exposed credential, (ii) identifying a responsible entity of that resource, and (iii) alerting the responsible entity about the exposed credential are disclosed. A credential is determined to be in an exposed state. The exposed credential, if used, could potentially provide an actor access to a resource, despite the fact that the actor should not have access to the resource. The exposed credential is analyzed to determine a context. Based on that context, the resource is identified. A responsible entity associated with the resource is identified. An alert is then sent to that entity.

Abstract: Techniques for identifying an exposed credential that, if used, would provide access to a resource are disclosed. The techniques enable the resource to remain online while (i) a new credential is allocated for the resource, (ii) the resource is transitioned to using the new credential instead of the exposed credential, and (iii) the exposed credential is attempted to be invalidated. A credential is accessed. This credential is suspected of being in an exposed state. The credential is accessible from within an artifact and is determined to be in the exposed state. A new credential is generated. This new credential is designed to replace the exposed credential. An instruction is transmitted to the resource to cause it to transition from using the exposed credential to using the new credential. The exposed credential is then invalidated.

Abstract: Integrating super-app extension discovery and configuration within source code management platform comments. Based on a triggering event associated with a context within a code repository, a super-app identifies a set of extensions available for execution against the context, and triggers execution of at least a subset of the set of extensions against the context. The super-app generates a super-app output that includes an output of having triggered the subset of extensions against the context, a listing of one or more of the set of extensions as being a library of available extensions to the super-app, and an indication of a comment-based syntax for configuring an extension to the super-app. The super-app posts that output as a comment on a comment feed. Based on user input received via a comment using the comment-based syntax, the super-app generates a modified super-app configuration associated with the code repository.

Abstract: Integrating super-app extension discovery and configuration within source code management platform comments. Based on a triggering event associated with a context within a code repository, a super-app identifies a set of extensions available for execution against the context, and triggers execution of at least a subset of the set of extensions against the context. The super-app generates a super-app output that includes an output of having triggered the subset of extensions against the context, a listing of one or more of the set of extensions as being a library of available extensions to the super-app, and an indication of a comment-based syntax for configuring an extension to the super-app. The super-app posts that output as a comment on a comment feed. Based on user input received via a comment using the comment-based syntax, the super-app generates a modified super-app configuration associated with the code repository.

Abstract: The estimation and visualization of a degree of change between a further edited state of code and a selected version of the code. For each of some counted added or deleted portions (e.g., code lines) of code, the system estimates that the added (or deleted) portion complies with a non-review characteristic. The added (or deleted) code lines that comply with a non-review characteristic are excluded from the estimation of the degree of change. Thus, the estimation excludes consideration of added or deleted portions that need no substantial review, while considering more substantial added or deleted portions in the estimations. The estimation is then visualize giving the developer or the reviewer a better idea of the scale of changes that has really been made since the selected version of the code.

Abstract: The estimation and visualization of a degree of change between a further edited state of code and a selected version of the code. For each of some counted added or deleted portions (e.g., code lines) of code, the system estimates that the added (or deleted) portion complies with a non-review characteristic. The added (or deleted) code lines that comply with a non-review characteristic are excluded from the estimation of the degree of change. Thus, the estimation excludes consideration of added or deleted portions that need no substantial review, while considering more substantial added or deleted portions in the estimations. The estimation is then visualize giving the developer or the reviewer a better idea of the scale of changes that has really been made since the selected version of the code.

Abstract: The factorization of test components when performing component-level regression testing in iterative builds of a computing system that consists of many working components. Performance metrics for test components are maintained across multiple builds of the computing program. To perform factorization, multiple factorings of a test component are identified and evaluated until a suitable improvement in the maintained performance metric for each corresponding test component is achieved (e.g., via simulation). This may be performed, across multiple of the test components. This process may be iterated through such that the set of test components being factored and evaluated in a subsequent iteration may in fact be a test component created by factorization in a prior iteration. The net result is that the factorization achieves improvement in performance metrics of the test components.

Abstract: The factorization of test components when performing component-level regression testing in iterative builds of a computing system that consists of many working components. Performance metrics for test components are maintained across multiple builds of the computing program. To perform factorization, multiple factorings of a test component are identified and evaluated until a suitable improvement in the maintained performance metric for each corresponding test component is achieved (e.g., via simulation). This may be performed, across multiple of the test components. This process may be iterated through such that the set of test components being factored and evaluated in a subsequent iteration may in fact be a test component created by factorization in a prior iteration. The net result is that the factorization achieves improvement in performance metrics of the test components.