19913d85-f662-4518-a9a1-7adc1793dfd4.png){kind=small}
Channels
dagster-de
dagster-cube
gigs-freelance
dagster-wandb
dagster-machine-learning
dagster-bigquery
tools
dagster-dask
dagster-snowflake
dagster-releases
data-platform-design
events
dagster-serverless
dagster-noteable
introductions
dagster-airflow
dagster-cloud
random
dagster-dbt
faq-read-me-before-posting
dagster-airbyte
dagster-spatial
dagster-support
announcements
github-discussions
豆瓣酱帮
dagster-feedback
dagstereo
dagster-ecs
dagster-kubernetes
jobs
dagster-showcase
Title
r
Ricky Kim
09/14/2022, 1:56 PMHi. We are trialing Dagster Serverless, and noticed that sometimes after deploying to prod, workspace and assets show not the latest commit just pushed to prod, but workspace and assets used to be defined in an old commit.
If I rerun the Gitlab (we're using Gitlab) pipeline to redeploy, it shows correct workspace and assets, but I was wondering if this is a known behaviour.
d
daniel
09/14/2022, 2:43 PMHi Ricky - when the workspace is showing old data, did the gitlab pipeline complete successfully?
One thing we saw when writing our github action for serverless was that sometime if two commits landed close after each other, there could be an issue where they completed out of order and the earlier one ended up going in last. For that reason, we set up the built-in github action so that it only executes once at a time. Kind of a shot in the dark, but any chance that could be what's happening in your gitlab pipeline?
Specifically this is what we have in our github action to minimize the likelihood of CI/CD updates happening out of order: https://github.com/dagster-io/dagster-cloud-serverless-quickstart/blob/main/.github/workflows/deploy.yml#L7-L10
concurrency:
# Cancel in-progress deploys to main branch
group: ${{ github.ref }}
cancel-in-progress: truer
Ricky Kim
09/15/2022, 7:24 AMHi Daniel.
Thank you for your answer.
Regarding your question, yes gitlab pipeline completed successfully when this happened.
And I will try to apply the similar setting to the gitlab pipeline, and see if it fixes the problem.
Hi Daniel.
I have checked the concurrency issue, but I doubt it's the source of the issue.
Currently I am the only one working on the repo. And the Gitlab setting for concurrency is set to run only one prod pipeline for the repo at any time.
To give you a bit more context,
I have added
--commit-hashdagster-cloud serverless deploy --location-name "moo" --package-name moo --deployment prod --commit-hash $CI_COMMIT_SHAd
daniel
09/16/2022, 2:55 PMGot it - is your deployment currently in the bad state? If so, do you have a link to page that's showing old content currently?
Happy to jump on a call quickly if that would be helpful