Where do you read

INPUT_PR

from in branch deployments as in here? When I export

INPUT_PR

from github actions, it still doesn’t read it.

Cross-post from dagster support channel:

HI Jeremy - as luck would have it a fix for this is already going live in Cloud today: https://github.com/dagster-io/dagster/pull/9742

Cross-posting from dagster-support:

Anyone with the same problem?

Hey, I’m trying to setup branch deployments for an existing repo but I’m getting several different errors. We are using an hybrid cloud with a k8s. To simplify the process, I now created a new repo from the quickstart template - https://github.com/dagster-io/dagster-cloud-hybrid-quickstart . I set

DAGSTER_CLOUD_API_TOKEN

and

ORGANIZATION_ID

, updated the registry in

dagster_cloud.yml

and setup the auth to login to my gcp registry so far so good. When I try to run the Hybrid Branch Deployments action, the build works, but it’s failing on one of the notification steps:

Traceback (most recent call last):
  File "/create_or_update_comment.py", line 86, in <module>
    main()
  File "/create_or_update_comment.py", line 27, in main
    pr_id = int(os.getenv("INPUT_PR"))
ValueError: invalid literal for int() with base 10: ''

Any clue to why this is happening? From what I can tell, the value of the

pr

variable gets set in this action https://github.com/dagster-io/dagster-cloud-action/blob/main/actions/hybrid_branch_deploy/action.yml based on

"${{ github.event.number }}"

. Does this mean it’s getting an empty value? Did I miss a setup in setting up this example repo?

cc @Marco Salazar

Hey, I noticed that the (hybrid) branch deployment script fails when you merge a PR and your github repository is set to delete branches. It appears that the

Parse cloud workspace

script fails to checkout the code because it’s attempting to pull a branch that no longer exists. (I’m using a sample repo creating using the quickstart template - https://github.com/dagster-io/dagster-cloud-hybrid-quickstart). Was able to recreate and temporarily fix by turning on and off the

Automatically delete head branches

feature for my repo. My knowledge of github actions is limited, but I think that the fix requires telling the checkout step which reference to use: Edit: this doesn’t seem to work either 🤔

jobs:
  parse_workspace:
    runs-on: ubuntu-latest
    outputs:
      build_info: ${{ steps.parse-workspace.outputs.build_info }}
    steps:
      - name: Checkout repo
        uses: actions/checkout@v3
        with:
          ref: ${{ github.head_ref }}

hello, i'm noticing that if you set up an alert that has multiple tags that share the same tag key but different values, only the latest one for that tag is respected. is that expected behavior? Alerts can still refer to multiple tags, but they must have different tag keys.

• is there a plan to support dagster serverless on gcp? • we have a private python library repo, what would be recommended way to bundle this via dagster serverless deployment?

👋 Hey folks, quick question regarding SSO. We’re currently using github accounts for our sso, but are looking into maybe swapping over to google workspaces instead. Would enabling workspace SSO as per the guide disable github integration? Essentially we’re considering migrating to google workspace SSO instead of github, and want to know if we should expect any sort of lock out of our existing dagster users.

hi, trying out dagster cloud hybrid mode • I got a docker agent running successfully • I cloned https://github.com/dagster-io/dagster-cloud-hybrid-quickstart and only changed registry uri • at github actions, during post-deployment checks, I got this error:

Waiting for agent to sync changes to example_location...
Still waiting for agent to sync changes to example_location. This can take a few minutes.
Still waiting for agent to sync changes to example_location. This can take a few minutes.
Still waiting for agent to sync changes to example_location. This can take a few minutes.
Still waiting for agent to sync changes to example_location. This can take a few minutes.
Still waiting for agent to sync changes to example_location. This can take a few minutes.
Still waiting for agent to sync changes to example_location. This can take a few minutes.
Error: Some locations failed to load after being synced by the agent:
Error loading example_location: {'__typename': 'PythonError', 'message': 'docker.errors.APIError: 500 Server Error for <http+docker://localhost/v1.41/images/create?tag=1357a2e2f206e4f5a33a46efd6bb13b81b6e0b75&fromImage=***.dkr.ecr.***.amazonaws.com%2Fdagster-cloud-hybrid-quickstart>: Internal Server Error ("Head "https://***.dkr.ecr.***.<http://amazonaws.com/v2/dagster-cloud-hybrid-quickstart/manifests/1357a2e2f206e4f5a33a46efd6bb13b81b6e0b75|amazonaws.com/v2/dagster-cloud-hybrid-quickstart/manifests/1357a2e2f206e4f5a33a46efd6bb13b81b6e0b75>": no basic auth credentials")\n', 'stack': ['  File "/dagster-cloud/dagster_cloud/workspace/user_code_launcher/user_code_launcher.py", line 779, in _reconcile\n    new_server_handles[to_update_key] = self._start_new_server_spinup(\n', '  File "/dagster-cloud/dagster_cloud/workspace/docker/__init__.py", line 190, in _start_new_server_spinup\n    for _line in docker.APIClient().pull(metadata.image, stream=True):\n', '  File "/usr/local/lib/python3.8/site-packages/docker/api/image.py", line 429, in pull\n    self._raise_for_status(response)\n', '  File "/usr/local/lib/python3.8/site-packages/docker/api/client.py", line 270, in _raise_for_status\n    raise create_api_error_from_http_exception(e) from e\n', '  File "/usr/local/lib/python3.8/site-packages/docker/errors.py", line 39, in create_api_error_from_http_exception\n    raise cls(e, response=response, explanation=explanation) from e\n']}

• I have tested that on a machine running docker agent, it can pull the dagster image wondering what could the error be from 🙏

I feel like this might be a long shot, but I'm exploring the idea of creating a custom run launcher to launch some runs end to end on Databricks, but I'm realizing I don't even really know where the run launcher is configured in dagster cloud (feels silly but it's been a while since I set it up). I see there's a user code launcher config for the agent in the CloudFormation template, but it's unclear if that's the same thing as a run launcher. as a follow-up, is it possible to have multiple run launchers, maybe associated with different user code deployments?

Is there a way to validate the integrity of a code location before we actually deploy it to Dagster cloud? I recently made some changes and accidentally broke the configuration I used for the production deployment. In this case, it’s a dict of dicts of

.configured()

resources. The dict for the

prod

environment was accidentally a set and not a dict. Also, for extra points - is it possible to add an option to Dagster cloud to only replace a running code location pod if the new one starts successfully?

Are there any news regarding dagster/ dagster-cloud supporitng SLA? I.e. usually a job should run for 5 minutes if it takes > 2x the time perhaps kill the job or at least send a message regarding SLA issue. For example, I recently had a long running transaction locking a table where dagsters IO manager wanted to write to - and therefore delay the data pipeline forever. In such a case I would want dagster to send a notification or kill the job

cross-posting from #dagster-support https://dagster.slack.com/archives/C01U954MEER/p1665692593095289

All of my dagster cloud jobs have been failing before they start in the last hour with the message: “Exception: No container in task definition with expected name dagster”. Status page looks normal though?

Hi, what'd be the recommended way to add environment variables in a hybrid setup?

in hybrid deployment, are we still required to specify

storage

config in

dagster.yaml

? https://docs.dagster.io/deployment/dagster-instance#compute-log-storage

Hi, I would like to use multiple ECS Task Definitions for each job in Dagster Cloud. What settings would be needed to do this?

DAGSTER_HOME

is set in workspace.yaml and dagster.yaml is placed in the

DAGSTER_HOME

path of the Docker Image, but the configuration is not reflected.

Our scheduled jobs stopped yesterday, but refreshing code locations seems to have fixed it. I'm curious if anyone recognizes the error so we can avoid it recurring:

DagsterUserCodeUnreachableError("Could not reach user code server") from e

The above exception was caused by the following exception:
grpc._channel._InactiveRpcError: <_InactiveRpcError of RPC that terminated with:
	status = StatusCode.UNAVAILABLE
	details = "DNS resolution failed for my-job-name-93ab65:4000: C-ares status is not ARES_SUCCESS qtype=A name=my-job-name-93ab65 is_balancer=0: Domain name not found"
	debug_error_string = "{"created":"@1666703037.379755003","description":"DNS resolution failed for my-job-name-93ab65:4000: C-ares status is not ARES_SUCCESS qtype=A name=my-job-name-93ab65 is_balancer=0: Domain name not found","file":"src/core/lib/transport/error_utils.cc","file_line":165,"grpc_status":14}"
>

How can we configure our Dagster cloud setup in such a way that every user has their own deployment. At the moment, every user is taken straight to the production branch.

Hi, o have issues with branch deployment in hybrid mode It deploys to prod deployment successfully. However on branch deployment mode, dagster cloud doesn’t register a runner, only agent managed by dagster is listed (and the deployment mode switch button only has switch to serverless option) Also tried a separate yaml config for branch deployment agent as well, also try a different docker network, to mo avail.

are there any examples of the `dagster-cloud/utils/run` github action or how I'd use it in a GH Action? I am not seeing a way to pass in an auth token to auth against the API. Here's what I'm currently attempting:

- name: Run Dagster Test Job
        uses: dagster-io/dagster-cloud-action/actions/utils/run@v0.1
        with:
          dagster_cloud_url: <https://my_url.dagster.cloud>
          deployment: my_deployment
          location: my_code_location_name
          repository: my_repo_name
          job: my_job_name

Tried passing in

dagster_cloud_api_token

but got:

Warning: Unexpected input(s) 'dagster_cloud_api_token', valid inputs are ['entryPoint', 'args', 'organization_id', 'deployment', 'location', 'location_name', 'repository', 'job', 'tags_json', 'config_json', 'dagster_cloud_url']

Is there a way to set the Dagster Cloud agent's name, as would show up in the Deployment > Agents page? I thought I remembered hearing about it, but I don't see it mentioned in the Helm values or k8s agent docs.

Afternoon Folks! I think I’m having a dagster cloud issue; I’m getting this error on my sensor ticks:

dagster._core.errors.DagsterUserCodeUnreachableError: Could not send request to agent since no agents have recently heartbeated

This happens on a

make_slack_run_on_failure_sensor

. More details in comments 👀

Found out that if I set

ENTRYPOINT

in

Dockerfile

(hybrid mode) (was migrating stuff from existing workflow and forgot to clean them up), when using branch deployment, the runner heartbeat is registered, but it throws

DNS resolution failed

error. Upon removing

ENTRYPOINT

directive, everything works normally I think this edge case could use a better error message 🚀

hey guys, all my jobs are failing suddenly with the k8s agent. how do I shut it down?

Hey! We got the following error for our schedules today:

dagster._core.scheduler.scheduler.DagsterSchedulerError: Unable to reach the user code server for schedule job1*. Schedule will resume execution once the server is available.

Any ideas?

I've changed the name of my Dagster Cloud repo on GitHub (as I was originally using the starter template) and I'm not sure how to get Dagster Cloud to update with the new repository name / GH link. I've made a branch deploy since the rename and that seemed to work OK, though various parts of the Dagster Cloud UI are still referencing the old repo name / link (

dagster-starter

). How can I change these?