https://pipedream.com/projects
production
branch through the Pipedream UI or GitHub.
When you merge a Git-backed project to production, all modified resources in the project will be deployed. Multiple workflows may be deployed, modified, or deleted in production through a single merge action.
production
. Validate your changes and click Merge to production to complete the merge:
undeployed-changes
(e.g., undeployed-changes-27361
).production
branch will trigger a deploy for your Pipedream workflows.
workflow.yaml
configuration file. Pipedream requires this prefix to correctly identify and resolve components specific to your workspace.
For example, if you modified a registry action and published it privately, the correct component key should be formatted as @workspacename/component-key@version
(e.g., @pipedream/github-update-issue@0.1.0
).
To resolve this error:
workflow.yaml
file where the component key is specified.@workspacename/component-key@version
.previous_github_repo
new_github_repo
previous_github_repo
in GitHub.new_github_repo
.old_github_repo
into migration, allowing for unrelated histories:
migration
branch to the remote:
production
branch and merge:
previous_github_repo
from GitHub.
production
branch work?production
branch will be deployed to your production workflows on Pipedream.
From a design perspective, we want to let you manage any branching strategy on your end, since you may be making commits to the repo outside of Pipedream. Once we support managing Pipedream workflows in a monorepo, where you may have other changes, we wanted to use a branch that didn’t conflict with a conventional main branch (like main
or master
).
In the future, we also plan to support you changing the default branch name.