db_v1_queries_deployment - OmniCloudOrg/OmniOrchestrator GitHub Wiki
Path: src/db/v1/queries/deployment.rs
- async fn list_builds
- async fn get_build_by_id
- async fn create_build
- async fn update_build_status
- async fn get_latest_successful_build
- async fn delete_build
- async fn get_app_builds
- async fn list_deployments
- async fn get_deployment_by_id
- async fn create_deployment
- async fn update_deployment_status
- async fn get_latest_deployment
- async fn get_successful_deployments
- async fn delete_deployment
- async fn get_app_deployments
- async fn get_deployment_with_build
pub async fn list_builds(pool: &Pool<MySql>, app_id: i64) -> anyhow::Result<Vec<Build>> {
let builds = sqlx::query_as::<_, Build>(
"SELECT * FROM builds WHERE app_id = ? ORDER BY created_at DESC",
)
.bind(app_id)
.fetch_all(pool)
.await
.context("Failed to fetch builds")?;
Retrieves all builds for a specific application, ordered by creation time. This function fetches the complete build history for an application, with the most recent builds first. It's useful for displaying the build timeline and history of an application.
-
pool
- Database connection pool for executing the query -
app_id
- Unique identifier of the application whose builds to retrieve
-
Ok(Vec<Build>)
- Successfully retrieved list of builds for the application -
Err(anyhow::Error)
- Failed to fetch builds
This function returns all builds without pagination. For applications with a large number of builds, consider using get_app_builds
which supports pagination.
pub async fn get_build_by_id(pool: &Pool<MySql>, id: i64) -> anyhow::Result<Build> {
let build = sqlx::query_as::<_, Build>("SELECT * FROM builds WHERE id = ?")
.bind(id)
.fetch_one(pool)
.await
.context("Failed to fetch build")?;
Retrieves a specific build by its unique identifier. This function fetches detailed information about a single build record. It's typically used when detailed build information is needed, such as for displaying build details or for triggering a deployment based on a build.
-
pool
- Database connection pool for executing the query -
id
- Unique identifier of the build to retrieve
-
Ok(Build)
- Successfully retrieved build information -
Err(anyhow::Error)
- Failed to fetch build (including if not found)
Returns an error if no build with the given ID exists or if a database error occurs during the query execution.
pub async fn create_build(
pool: &Pool<MySql>,
app_id: i64,
source_version: Option<&str>,
) -> anyhow::Result<Build> {
// ... function body
}
Creates a new build record for an application. This function initiates a build process by creating a build record in the database. The build starts in a 'pending' status and can be updated as the build process progresses.
-
pool
- Database connection pool for executing the query -
app_id
- Identifier of the application this build belongs to -
source_version
- Optional source version identifier (e.g., git commit hash or tag)
-
Ok(Build)
- Successfully created build record -
Err(anyhow::Error)
- Failed to create build record
This function uses a database transaction to ensure atomicity of the operation. If any part of the operation fails, the entire operation is rolled back.
pub async fn update_build_status(
pool: &Pool<MySql>,
id: i64,
status: &str,
started_at: Option<DateTime<Utc>>,
completed_at: Option<DateTime<Utc>>,
) -> anyhow::Result<Build> {
// ... function body
}
Updates the status and timing information of an existing build. This function modifies a build record to reflect its current state and progress. It's typically called during the build lifecycle to update status from 'pending' to 'in_progress' to 'succeeded' or 'failed', along with appropriate timestamps.
-
pool
- Database connection pool for executing the query -
id
- Unique identifier of the build to update -
status
- New status of the build (e.g., 'pending', 'in_progress', 'succeeded', 'failed') -
started_at
- Optional timestamp when the build process started -
completed_at
- Optional timestamp when the build process completed
-
Ok(Build)
- Successfully updated build record -
Err(anyhow::Error)
- Failed to update build
A typical build status lifecycle might be: 1. 'pending' - Build is queued but not yet started 2. 'in_progress' - Build process has begun (set started_at) 3. 'succeeded' or 'failed' - Build has completed (set completed_at)
This function uses a database transaction to ensure atomicity of the operation. If any part of the operation fails, the entire operation is rolled back.
pub async fn get_latest_successful_build(pool: &Pool<MySql>, app_id: i64) -> anyhow::Result<Build> {
let build = sqlx::query_as::<_, Build>(
r#"SELECT * FROM builds
WHERE app_id = ? AND status = 'succeeded'
ORDER BY created_at DESC LIMIT 1"#,
)
.bind(app_id)
.fetch_one(pool)
.await
.context("Failed to fetch latest successful build")?;
Retrieves the most recent successful build for an application. This function finds the latest build with a 'succeeded' status for a given application. It's commonly used for initiating deployments or for reporting the latest successful build.
-
pool
- Database connection pool for executing the query -
app_id
- Unique identifier of the application
-
Ok(Build)
- Successfully retrieved the latest successful build -
Err(anyhow::Error)
- Failed to fetch build or no successful build exists
Returns an error if no successful builds exist for the application or if a database error occurs during the query execution.
Common use cases include: - Determining what to deploy when a user requests "deploy latest build" - Showing the latest valid build in the application dashboard - Computing time since last successful build for metrics
pub async fn delete_build(pool: &Pool<MySql>, id: i64) -> anyhow::Result<()> {
let mut tx = pool.begin().await?;
Deletes a specific build from the database. This function permanently removes a build record and should be used with caution. It's typically used for cleanup operations or removing invalid builds.
-
pool
- Database connection pool for executing the query -
id
- Unique identifier of the build to delete
-
Ok(())
- Successfully deleted the build -
Err(anyhow::Error)
- Failed to delete the build
This operation is irreversible. Consider the implications before deleting builds, especially if they're referenced by deployments or other records.
This function uses a database transaction to ensure atomicity of the operation. If any part of the operation fails, the entire operation is rolled back.
pub async fn get_app_builds(
pool: &Pool<MySql>,
app_id: i64,
limit: i64,
offset: i64,
) -> anyhow::Result<Vec<Build>> {
// ... function body
}
Retrieves a paginated list of builds for a specific application. This function fetches builds associated with a particular application, with pagination support. Results are ordered by creation time in descending order (newest first).
-
pool
- Database connection pool for executing the query -
app_id
- Unique identifier of the application whose builds to retrieve -
limit
- Maximum number of builds to return -
offset
- Number of builds to skip (for pagination)
-
Ok(Vec<Build>)
- Successfully retrieved paginated list of builds -
Err(anyhow::Error)
- Failed to fetch builds
The offset-based pagination works as follows: - First page: offset=0, limit=N - Second page: offset=N, limit=N - Third page: offset=2*N, limit=N
This function is preferred over list_builds
when dealing with applications that have a large number of builds, as it allows for efficient pagination.
pub async fn list_deployments(pool: &Pool<MySql>, app_id: i64) -> anyhow::Result<Vec<Deployment>> {
let deployments = sqlx::query_as::<_, Deployment>(
"SELECT * FROM deployments WHERE app_id = ? ORDER BY created_at DESC",
)
.bind(app_id)
.fetch_all(pool)
.await
.context("Failed to fetch deployments")?;
Retrieves all deployments for a specific application, ordered by creation time. This function fetches the complete deployment history for an application, with the most recent deployments first. It's useful for displaying the deployment timeline and history of an application.
-
pool
- Database connection pool for executing the query -
app_id
- Unique identifier of the application whose deployments to retrieve
-
Ok(Vec<Deployment>)
- Successfully retrieved list of deployments -
Err(anyhow::Error)
- Failed to fetch deployments
This function returns all deployments without pagination. For applications with a large number of deployments, consider using get_app_deployments
which supports pagination.
pub async fn get_deployment_by_id(pool: &Pool<MySql>, id: i64) -> anyhow::Result<Deployment> {
let deployment = sqlx::query_as::<_, Deployment>("SELECT * FROM deployments WHERE id = ?")
.bind(id)
.fetch_one(pool)
.await
.context("Failed to fetch deployment")?;
Retrieves a specific deployment by its unique identifier. This function fetches detailed information about a single deployment record. It's typically used when detailed deployment information is needed, such as for displaying deployment details or checking deployment status.
-
pool
- Database connection pool for executing the query -
id
- Unique identifier of the deployment to retrieve
-
Ok(Deployment)
- Successfully retrieved deployment information -
Err(anyhow::Error)
- Failed to fetch deployment (including if not found)
Returns an error if no deployment with the given ID exists or if a database error occurs during the query execution.
pub async fn create_deployment(
pool: &Pool<MySql>,
app_id: i64,
build_id: i64,
) -> anyhow::Result<Deployment> {
// ... function body
}
Creates a new deployment record for an application based on a specific build. This function initiates a deployment process by creating a deployment record in the database. The deployment starts in a 'pending' status and can be updated as the deployment process progresses.
-
pool
- Database connection pool for executing the query -
app_id
- Identifier of the application this deployment belongs to -
build_id
- Identifier of the build to deploy
-
Ok(Deployment)
- Successfully created deployment record -
Err(anyhow::Error)
- Failed to create deployment record
This function uses a database transaction to ensure atomicity of the operation. If any part of the operation fails, the entire operation is rolled back.
Each deployment is associated with: - An application (app_id) - A specific build (build_id) that is being deployed This allows tracking which version of the application is deployed and when.
pub async fn update_deployment_status(
pool: &Pool<MySql>,
id: i64,
status: &str,
started_at: Option<DateTime<Utc>>,
completed_at: Option<DateTime<Utc>>,
) -> anyhow::Result<Deployment> {
// ... function body
}
Updates the status and timing information of an existing deployment. This function modifies a deployment record to reflect its current state and progress. It's typically called during the deployment lifecycle to update status from 'pending' to 'in_progress' to 'deployed' or 'failed', along with appropriate timestamps.
-
pool
- Database connection pool for executing the query -
id
- Unique identifier of the deployment to update -
status
- New status of the deployment (e.g., 'pending', 'in_progress', 'deployed', 'failed') -
started_at
- Optional timestamp when the deployment process started -
completed_at
- Optional timestamp when the deployment process completed
-
Ok(Deployment)
- Successfully updated deployment record -
Err(anyhow::Error)
- Failed to update deployment
A typical deployment status lifecycle might be: 1. 'pending' - Deployment is queued but not yet started 2. 'in_progress' - Deployment process has begun (set started_at) 3. 'deployed' or 'failed' - Deployment has completed (set completed_at)
This function uses a database transaction to ensure atomicity of the operation. If any part of the operation fails, the entire operation is rolled back.
pub async fn get_latest_deployment(pool: &Pool<MySql>, app_id: i64) -> anyhow::Result<Deployment> {
let deployment = sqlx::query_as::<_, Deployment>(
r#"SELECT * FROM deployments
WHERE app_id = ?
ORDER BY created_at DESC
LIMIT 1"#,
)
.bind(app_id)
.fetch_one(pool)
.await
.context("Failed to fetch latest deployment")?;
Retrieves the most recent deployment for an application. This function finds the latest deployment for a given application, regardless of its status. It's commonly used for checking the current deployment status or for display in application dashboards.
-
pool
- Database connection pool for executing the query -
app_id
- Unique identifier of the application
-
Ok(Deployment)
- Successfully retrieved the latest deployment -
Err(anyhow::Error)
- Failed to fetch deployment or no deployments exist
Returns an error if no deployments exist for the application or if a database error occurs during the query execution.
Common use cases include: - Showing the current deployment status in application dashboards - Determining if a deployment is in progress - Computing time since last deployment for metrics
pub async fn get_successful_deployments(
pool: &Pool<MySql>,
app_id: i64,
limit: i64,
) -> anyhow::Result<Vec<Deployment>> {
// ... function body
}
Retrieves successful deployments for a specific application. This function fetches deployments with 'deployed' status for a given application, limited to a specified number and ordered by creation time (newest first). It's useful for displaying deployment history or for rollback operations.
-
pool
- Database connection pool for executing the query -
app_id
- Unique identifier of the application -
limit
- Maximum number of successful deployments to retrieve
-
Ok(Vec<Deployment>)
- Successfully retrieved list of deployments -
Err(anyhow::Error)
- Failed to fetch deployments
Common use cases include: - Providing a list of deployments that can be rolled back to - Showing deployment history in application dashboards - Tracking successful deployment frequency for metrics
pub async fn delete_deployment(pool: &Pool<MySql>, id: i64) -> anyhow::Result<()> {
let mut tx = pool.begin().await?;
Deletes a specific deployment from the database. This function permanently removes a deployment record and should be used with caution. It's typically used for cleanup operations or removing invalid deployments.
-
pool
- Database connection pool for executing the query -
id
- Unique identifier of the deployment to delete
-
Ok(())
- Successfully deleted the deployment -
Err(anyhow::Error)
- Failed to delete the deployment
This operation is irreversible. Consider the implications before deleting deployments, especially for applications in production environments.
This function uses a database transaction to ensure atomicity of the operation. If any part of the operation fails, the entire operation is rolled back.
pub async fn get_app_deployments(
pool: &Pool<MySql>,
app_id: i64,
limit: i64,
offset: i64,
) -> anyhow::Result<Vec<Deployment>> {
// ... function body
}
Retrieves a paginated list of deployments for a specific application. This function fetches deployments associated with a particular application, with pagination support. Results are ordered by creation time in descending order (newest first).
-
pool
- Database connection pool for executing the query -
app_id
- Unique identifier of the application whose deployments to retrieve -
limit
- Maximum number of deployments to return -
offset
- Number of deployments to skip (for pagination)
-
Ok(Vec<Deployment>)
- Successfully retrieved paginated list of deployments -
Err(anyhow::Error)
- Failed to fetch deployments
The offset-based pagination works as follows: - First page: offset=0, limit=N - Second page: offset=N, limit=N - Third page: offset=2*N, limit=N
This function is preferred over list_deployments
when dealing with applications that have a large number of deployments, as it allows for efficient pagination.
pub async fn get_deployment_with_build(
pool: &Pool<MySql>,
deployment_id: i64,
) -> anyhow::Result<(Deployment, Build)> {
// ... function body
}
Retrieves a deployment with its associated build information. This function fetches a deployment record together with the build it's associated with, combining the data in a single query. This is more efficient than making separate queries for deployment and build information.
-
pool
- Database connection pool for executing the query -
deployment_id
- Unique identifier of the deployment to retrieve
-
Ok((Deployment, Build))
- Successfully retrieved deployment and build information -
Err(anyhow::Error)
- Failed to fetch data (including if not found)
Common use cases include: - Displaying detailed deployment information including the build being deployed - Getting complete information for logs or auditing - Providing comprehensive information for deployment status pages
This function performs a JOIN operation to fetch both deployment and build data in a single query, which is more efficient than making two separate database calls.