Skip to content

Add base_deployment_name to get branch deployment action#232

Open
benpankow wants to merge 4 commits intomainfrom
benpankow/add-option-to-allow-adjusting-base-deployment-name
Open

Add base_deployment_name to get branch deployment action#232
benpankow wants to merge 4 commits intomainfrom
benpankow/add-option-to-allow-adjusting-base-deployment-name

Conversation

@benpankow
Copy link
Member

@benpankow benpankow commented Jul 1, 2025

Summary

Adds the option to configure a base_deployment_name for the serverless, hybrid deploy actions and the get branch deployment action.

Test Plan

Tested against prod with test org.

@benpankow
Copy link
Member Author

benpankow commented Jul 1, 2025

This stack of pull requests is managed by Graphite. Learn more about stacking.

@github-actions
Copy link

github-actions bot commented Jul 1, 2025

Your pull request is automatically being deployed to Dagster Cloud.

Location Status Link Updated
from_gh_action View in Cloud Jul 02, 2025 at 10:57 PM (UTC)

Copy link
Member

@gibsondan gibsondan left a comment

Choose a reason for hiding this comment

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

see inline - wondering if we should strive for consistency with the 'dagster-cloud ci init' behavior here?

It is admittedly odd that that does not apply to the 'dagster-cloud branch-deployment' command

@@ -62,6 +62,7 @@ runs:
run: >
Copy link
Member

Choose a reason for hiding this comment

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

i think in other contexts we use this input to be the base deployment to use if its a PR, and the actual deployment name to be used if its a full deployment. I have mixed feelings about that but we should probably be consistent? i.e. can we get away without needing a new input here?

See for example https://github.com/dagster-io/dagster-cloud-action/blob/main/actions/utils/ci-init/action.yml#L11-L14 from the 'new' github action flow

If we do add an input we should document it here

Copy link
Member Author

Choose a reason for hiding this comment

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

Updated this action to re-use the same input. The others it's a little tricky to, so I left the new input.

I can't say I have a great understanding of which actions are in use right now - at some point we can deprecate the non ci ones, right?

@gibsondan gibsondan requested a review from shalabhc July 1, 2025 19:13
@benpankow benpankow requested a review from gibsondan July 2, 2025 23:04
Copy link
Member

@gibsondan gibsondan left a comment

Choose a reason for hiding this comment

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

hm ok sorry for the back and forth here - if we can't fully port it over (which is not the end of the world) I think inconsistency between the old dagster-cloud action and the new dagster-cloud action setup is preferable to inconsistency within a single action YAML file (i.e. if I am understanding htis now, you would set it in two different ways in this one file here, one for the PEX flow and one for the docker flow, which seems even more confusing: https://github.com/dagster-io/dagster/blob/bb6628650877f9ef7a780ebc2e6a349c92c03f2c/examples/assets_dbt_python/.github/workflows/examples/branch_deployments.yml#L1-L86)

So i think going back to the old way where we were always explicitly passing in the base_deployment_name everywhere is fine (and arguably how the new CLI flow should work too)

Hoping we can fully move off of these old actions soon, the agent heartbeat fix is an attempt to remove the last blocker there

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.

2 participants