Abstract: Methods and systems are provided for comparing and identifying job definition files that are hard copies and soft copies of one another. In one embodiment, a method is provided that includes receiving and splitting a first job definition file into a first plurality of stages. The method further comprises comparing the first plurality of stages with a second plurality of stages from a second job definition file. Corresponding stages may be identified and used to determine whether the first and second job definition files are hard or soft copies of one another. If the first and second job definition files are hard copies, one of the job definition files may be deleted from a continuous integration environment. If the first and second job definition files are soft copies, a generic job definition file may be generated based on the first and second job definition files.

Abstract: A method and system for integrating business intelligence data into a continuous integration system are provided. In one embodiment, a method is provided comprising receiving business intelligence data regarding utilized product features and job data regarding tested product features. The method may further include converting the business intelligence data and the job data into unified business intelligence data and unified job data in a unified format. The method may also include generating a feature map based on the unified business intelligence data and unified job data, determining an insufficient mapping based on the feature map, and identifying a job flag based on the insufficient mapping.

Abstract: Implementing multiple load balancer drivers for a single load balancer is disclosed. A first request directed to a load balancer to load balance requests based on a first request selection instruction is received. A first particular load balancer driver is selected from a plurality of load balancer drivers based on a load balancer table that correlates request selection instructions to corresponding load balancer drivers of the plurality of load balancer drivers. Subsequent requests that are encompassed by the first request selection instruction directed to the load balancer are caused to be load balanced by the first particular load balancer driver.

Abstract: Computing resource coverage is disclosed. In an example, a computing resource (CR) pool includes a plurality of CR types hosted on a plurality of hosts, where the plurality of CR types are routinely updated. A test repository stores a plurality of test cases (TC). A processor is configured to execute a testing service to compile, from a plurality of test daemons, a CR manifest of the CR types included in the CR pool. A TC manifest is compiled, including CR types tested by the plurality of TCs. The CR types included in the CR manifest are compared with the CR types included in the TC manifest. A test coverage report of tested and untested CR types is generated. A TC is added to the test repository based on the test coverage report.

Abstract: Systems and methods are disclosed for derivation of executable tasks for synchronizing configuration parameters. An example method may comprise: obtaining a first set of configuration parameters of a first computer system corresponding to a first time value; obtaining a second set of configuration parameters of the first computer system corresponding to a second time value; performing a comparison between the first set of configuration parameters and the second set of configuration parameters to determine one or more differences; deriving in view of the comparison, one or more executable tasks to convert the first set of configuration parameters to the second set of configuration parameters; and providing, to a second computer system, the one or more executable tasks for execution by the second computer system to synchronize configuration parameters of the second computer system to configuration parameters of the first computer system corresponding to the second time value.

Abstract: Continuous debugging is disclosed. For example, a source code repository stores a first project. A processor is configured to execute a job scheduler, which includes a debugger. The job scheduler receives a request to execute a job, which includes executing a first executable code. A guest is instantiated. The first project is copied as a second project. The second project is compiled into the first executable code. The guest is instructed to execute the job including the first executable code. The debugger intercepts an error caused by executing the first executable code. The debugger updates the second project by inserting a breakpoint into the second project based on the error. The updated second project is compiled into a second executable code. The guest is instructed to re-execute the job including executing the second executable code. Execution of the second executable code is paused at the breakpoint.

Abstract: A task may be executed using a domain specific language (DSL) debugger, the task including one or more modules. A module debugger associated with a module of the one or more modules of the task may be identified. Task debugging data associated with the execution of the task using the DSL debugger may be transmitted to the identified module debugger. Module debugging data may be received from the identified module debugger. Multi-level debugging data including the task debugging data and the received module debugging data may be generated.

Abstract: Updating inactive compute instances is disclosed. It is determined that a first compute instance that boots from an operating system image on a first storage device is in an inactive state. It is determined that updates to the operating system image on the first storage device exist. The operating system image is copied from the first storage device to a second storage device. The operating system image on the second storage device is updated with the updates to generate an updated operating system image on the second storage device. The updated operating system image is copied form the second storage device to the first storage device in place of the operating system image.

Abstract: Virtualized computing resources can be managed in a cloud computing environment. For example, a system can receive input indicating that a cloud computing environment is to be reverted back to a prior state prior to an event occurring. Based on the input, the system can determine actions that were performed in the cloud computing environment in response to the event. Each action can involve a creation, a modification, or a deletion of a virtualized computing resource in the cloud computing environment. The system can determine a particular order in which the actions were performed by analyzing timestamps corresponding to the actions. The system can then revert the cloud computing environment back to the prior state by performing an inverse of each action in the plurality of actions in a reverse order to the particular order.

Abstract: A processing device in a system can allocate builds to execute jobs across servers in a distributed server environment such as a continuous integration (CI) or continuous deployment (CD) server environment, determine workload patterns, and store a workload pattern vector including a resource usage pattern for the builds and the servers. The processing device can provide an interface that allows a user to switch priorities of user-owned builds in server environments, even after execution of the jobs has begun. The user's ability to prioritize or reprioritize builds is limited to user-prioritizable builds as determined based on the resource usage patterns of the builds running the jobs. The user can thus prioritize some user-owned builds without adversely affecting builds of other users.

Abstract: Dynamically revising an in-process build is disclosed. A build system receives a build configuration comprising information that defines a plurality of successive stages. Each stage includes at least one step, and one or more of the stages include a plurality of successive steps. The build configuration defines a build process that, when completed, alters a state of a storage device. The build system initiates a build process sequence on the build configuration. The build system, after initiating the build process sequence, receives notification of a desire to add a revision to a particular stage of the plurality of stages defined in the build configuration. A determination is made that performance of the particular stage has or has not begun. In response to the determination, a subsequent build process action is performed.

Abstract: A processing device in a system can allocate builds to execute jobs across servers in a distributed server environment such as a continuous integration (CI) or continuous deployment (CD) server environment, determine workload patterns, and store a workload pattern vector including a resource usage pattern for the builds and the servers. The processing device can provide an interface that allows a user to switch priorities of user-owned builds in server environments, even after execution of the jobs has begun. The user's ability to prioritize or reprioritize builds is limited to user-prioritizable builds as determined based on the resource usage patterns of the builds running the jobs. The user can thus prioritize some user-owned builds without adversely affecting builds of other users.

Abstract: Methods, systems, and computer program products are included for incorporating functionalities of a version control system into a package manager. An example method includes providing to a package manager a source file path corresponding to a source. A software version control system corresponding to the source is determined from the source file path. A command translation driver corresponding to the software version control system of the source is loaded by the package manager. The loaded command translation driver translates a package manager command to a corresponding command of the software version control system. The translated package manager command is executed by the package manager.

Abstract: Systems and methods are disclosed for derivation of executable tasks for synchronizing configuration parameters. An example method may comprise: obtaining a first set of configuration parameters of a first computer system corresponding to a first time value; obtaining a second set of configuration parameters of the first computer system corresponding to a second time value; performing a comparison between the first set of configuration parameters and the second set of configuration parameters to determine one or more differences; deriving in view of the comparison, one or more executable tasks to convert the first set of configuration parameters to the second set of configuration parameters; and providing, to a second computer system, the one or more executable tasks for execution by the second computer system to synchronize configuration parameters of the second computer system to configuration parameters of the first computer system corresponding to the second time value.

Abstract: Deployment state based configuration generation is disclosed. For example, a first node is in a first deployment state, with a state daemon executing on the first node. A configuration generator may be associated with one or more processors. The state daemon records a first configuration instruction associated with a first modification to the first deployment state, where the first node is in a second deployment state after the first modification. The configuration generator generates a first configuration based on the second deployment state including the first configuration instruction. The first configuration is stored to a configuration repository, where the first configuration is deployed to a second node converting the second node to the second deployment state.