We re using ` changed since=origin main` on branch builds wh Pants #general

We're using `--changed-since=origin/main` on branc...

proud-planet-36170

04/02/2024, 1:47 PM

We're using

--changed-since=origin/main

on branch builds which is working great. However, not sure best practices for

main

branch builds. We're doing

merge

commits to

main

through PRs in Github, then this triggers CI that should run

package

and

publish

which then kicks off CD

package

step uses

HEAD

sha for Docker image tag (so

main

ends up with the

merge

commit sha which is different than what ran on the branch/PR CI) Not sure best practices/setup for CD off main while (ideally) having build avoidance. Maybe it's easier to force

squash

then do

--changed-since=HEAD~1

main

better-van-82973

04/02/2024, 1:57 PM

I avoid merge commits in general for this reason 🙂 What we do is basically the second option you said - all PRs are squashed and then merged, and CI + CD runs on the new commit in the

main

branch after merging. I’m thinking that may help avoid some of the issues you have with the

package

and

publish

steps running on the PR branch and then trying to deploy from

main

narrow-vegetable-37489

04/02/2024, 2:47 PM

GH probably have some variable that could help? We use

CI_COMMIT_BEFORE_SHA

in GitLab for main branch builds, it'll contain the previous commit.

gorgeous-winter-99296

04/02/2024, 2:53 PM

To find the previous commit to compare against, you're looking for

git merge-base main main~1

, which will give you the leftmost commit sha in this graph. when merging the blue branch.

gorgeous-winter-99296

04/02/2024, 2:55 PM

I'll add a note on this:

Copy code

package step uses HEAD sha for Docker image tag (so main ends up with the merge commit sha which is different than what ran on the branch/PR CI)

I'm not sure why this is a problem, really, but it does sound like you want to reuse the artifacts from the branch when publishing from main. This is dangerous! Consider what happens when you merge blue... If you reuse the state from the branch you'd not deploy any of the changes from yellow -- actually discarding two main commits! Maybe that isn't what you're trying to do, but I've seen it attempted leading to weird timing bugs 🙂 (Same thing happens if you don't enforce CI sequencing!)

proud-planet-36170

04/03/2024, 1:47 PM

Yeah, ideally we want branch Docker build and

main

build. The branch builds are useful for some test environments but we're not doing merge builds (where the branch is merged in prior to the build start) in CI so we'd want to do a merge build on the

main

branch for deploys to higher environments

proud-planet-36170

04/03/2024, 1:49 PM

For this monorepo setup, there's not too many dependencies between components--we're mostly just looking for a way to consolidate lots of small apps/scripts like AWS Lambdas so the build avoidance piece is pretty important

proud-planet-36170

04/03/2024, 1:51 PM

GH probably have some variable that could help?

It does but our CircleCI integration doesn't expose that so we'd need to give CCI a GH API key and add a call to GH API which I was trying to avoid (our current CircleCI setup doesn't have any GH API access, just ability to clone and receive events)

6 Views

Open in Slack

Previous Next