Skip to content

ci: Added build-image step to deploy-staging workflow#52

Open
Arshadul-Monir wants to merge 5 commits into
mainfrom
build-deploy-image
Open

ci: Added build-image step to deploy-staging workflow#52
Arshadul-Monir wants to merge 5 commits into
mainfrom
build-deploy-image

Conversation

@Arshadul-Monir

Copy link
Copy Markdown
Contributor

No description provided.

@Arshadul-Monir Arshadul-Monir requested a review from a team as a code owner July 10, 2026 16:28
@graphite-app graphite-app Bot requested a review from arklian July 10, 2026 16:29
@graphite-app

graphite-app Bot commented Jul 10, 2026

Copy link
Copy Markdown

Graphite Automations

"Request reviewers once CI passes" took an action on this PR • (07/10/26)

1 reviewer was added to this PR based on Henry Chen's automation.

Comment thread .github/scripts/src/update-tag/index.ts Outdated
Comment thread .github/scripts/src/build-image/index.ts Outdated
Comment thread .github/scripts/src/utils/run-local-db.ts Outdated
@spiffyy99 spiffyy99 self-requested a review July 10, 2026 23:22
ci: removed backend and database instance from ci
@Arshadul-Monir Arshadul-Monir force-pushed the build-deploy-image branch 3 times, most recently from f008b7a to 62275ca Compare July 11, 2026 23:30
Comment thread .github/workflows/deploy-staging.yml Outdated
@Arshadul-Monir Arshadul-Monir force-pushed the build-deploy-image branch 5 times, most recently from 331f01e to 29e230f Compare July 12, 2026 03:33
@Arshadul-Monir Arshadul-Monir requested a review from arklian July 12, 2026 03:59
@sonarqubecloud

Copy link
Copy Markdown

DOCKER_UPLOAD:
description: "Boolean indicating whether the image should be uploaded to Docker registry or not."
required: false
default: "true"

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is there a reason we'd want this to be false?

Comment thread .github/scripts/src/update-tag/index.ts Outdated

if (environment === "production") {
await ghClient.updateK8sTagWithPR({
manifestRepo: ["Patina-Network", "k8s-manifest"],

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if it's the repo name, isn't it k8s-manifests (as in plural) unless i'm missing some other context

kustomizationFilePath: "base/staging/patchats/kustomization.yaml",
imageName: "Patina-Network/patchats",
newTag: newTagVersion,
environment: "staging",

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if the only two environments are prod and staging, couldn't we just have one updateK8STagWithPR block? and sub in the environment into environment and kustomizationFilePath?

}

console.log(`Waiting for backend... (${i}/${MAX_ATTEMPTS})`);
await Bun.sleep(RETRY_DELAY_MS);

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is definitely not necessary for this case (it's probably too complicated/overengineered), but just for your own knowledge, most production retry systems use exponential backoff on subsequent attempts. Here's an example: https://bpaulino.com/entries/retrying-api-calls-with-exponential-backoff/

This is so we dont hammer the backend at regular intervals. Useful for if you ever implement this sort of thing at a larger scale :)

})();

const DATABASE_HOST = (() => {
const v = process.env["PG_HOST"];

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

could we make these blocks into a helper function? the logic is repeated 4 times

throw new Error("Missing DOCKER_HUB_PAT from platform-infra patchats.yaml");
}

// copy old tz format from build-image.sh

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this file exist in this repo?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Keeping .github/scripts/src/utils/run-local-db.ts and .github/scripts/src/utils/run-backend-instance.ts around is probably good.

run-local-db.ts tests that the migrations work from fresh, before we migrate staging or prod. We probably should only run this if there are .sql files in the changes tho, since it's kinda expensive/long.

run-backend-instance.ts is good to have around as a check that the server actually starts up, since we don't have integration tests set up yet.

Potentially can run them as separate actions, and think about which ones we can parallelize. We can add them back in, in a follow up PR instead of this one though.

with:
ENVIRONMENT: staging

buildImage:

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As Ryan said, this should probably be before migrate.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants