Repository navigation
Sync published Zapier 4.14.0 changes - #99
Merged
Merged
Conversation
delicb
marked this pull request as ready for review
August 10, 2026 13:59
smcgivern
approved these changes
Aug 10, 2026
Member
|
No idea how this works, happy to unblock you 🙂 |
Member
|
(Forgot to post draft comment.) |
Contributor
Author
|
Thanks, I just got into this as well 🙂. |
eliias
added a commit
that referenced
this pull request
Aug 12, 2026
Publishing this app is manual today, and the repo drifted from what Zapier runs: #99 had to reconstruct 4.10.0 through 4.14.0 out of the published app and back into git. A bot now opens one release PR when code that reaches Zapier changed since the last release, and merging it uploads the version and promotes it. It reads the last release from the last commit that changed the version field rather than a tag, because tagging stopped here in 2021 and the version field is what Zapier keys on. Existing Zaps keep the version they were built on, because nothing migrates them. The repo moves to Node 22, because the pinned Zapier CLI pulls dependencies that refuse to install below Node 20. Zapier still runs this app on Node 18, and will until we move to core 17. Check the promote step. It passes --yes, without which the CLI waits on a prompt nobody can answer on a runner, and that flag also accepts Zapier's non-blocking pre-check warnings. Towards INF-3414
eliias
added a commit
that referenced
this pull request
Aug 13, 2026
Publishing this app is manual today, and the repo drifted from what Zapier runs: #99 had to reconstruct 4.10.0 through 4.14.0 out of the published app and back into git. A bot now opens one release PR when code that reaches Zapier changed since the last release, and merging it uploads the version and promotes it. It reads the last release from the last commit that changed the version field rather than a tag, because tagging stopped here in 2021 and the version field is what Zapier keys on. Existing Zaps keep the version they were built on, because nothing migrates them. The repo moves to Node 22, because the pinned Zapier CLI pulls dependencies that refuse to install below Node 20. Zapier still runs this app on Node 18, and will until we move to core 17. Check the promote step. It passes --yes, without which the CLI waits on a prompt nobody can answer on a runner, and that flag also accepts Zapier's non-blocking pre-check warnings. Towards INF-3414
eliias
added a commit
that referenced
this pull request
Aug 13, 2026
Publishing this app is manual today, and the repo drifted from what Zapier runs: #99 had to reconstruct 4.10.0 through 4.14.0 out of the published app and back into git. A bot now opens one release PR when code that reaches Zapier changed since the last release, and merging it uploads the version and promotes it. It reads the last release from the last commit that changed the version field rather than a tag, because tagging stopped here in 2021 and the version field is what Zapier keys on. Existing Zaps keep the version they were built on, because nothing migrates them. A scheduled check compares the version in git with what Zapier holds, because the bot reads what shipped out of the version field, and that records intent rather than outcome. The repo moves to Node 22, because the pinned Zapier CLI pulls dependencies that refuse to install below Node 20. Zapier still runs this app on Node 18, and will until we move to core 17. Check the promote step. It passes --yes, without which the CLI waits on a prompt nobody can answer on a runner, and that flag also accepts Zapier's non-blocking pre-check warnings. Towards INF-3414
eliias
added a commit
that referenced
this pull request
Aug 13, 2026
Publishing this app is manual today, and the repo drifted from what Zapier runs: #99 had to reconstruct 4.10.0 through 4.14.0 out of the published app and back into git. One workflow now asks Zapier which versions it holds. If the version in package.json is not one of them, it uploads and promotes it. If it is, and code that reaches Zapier has changed since, it opens a version bump PR for a human to merge. Existing Zaps keep the version they were built on, because nothing migrates them. Asking Zapier beats inferring from a git push, which is what keeps this to one workflow instead of three: a release that half-failed is repaired on the next push to master rather than by a separate check. Where git is still consulted, for what changed since the last release, it reads the version field rather than a tag, because tagging stopped here in 2021 and the version field is what Zapier keys on. Check the promote step. It passes --yes, without which the CLI waits on a prompt nobody can answer on a runner, and that flag also accepts Zapier's non-blocking pre-check warnings. The repo moves to Node 22, because the pinned Zapier CLI pulls dependencies that refuse to install below Node 20. Zapier still runs this app on Node 18, and will until we move to core 17. Towards INF-3414
eliias
added a commit
that referenced
this pull request
Aug 13, 2026
Publishing this app is manual today, and the repo drifted from what Zapier runs: #99 had to reconstruct 4.10.0 through 4.14.0 out of the published app and back into git. Bump the minor version and write the changelog entry in the same PR as the code. CI fails the PR when code that reaches Zapier changes without that. Merging uploads that version to Zapier and promotes it, so new Zaps get it. Existing Zaps keep the version they were built on, because nothing migrates them. The release workflow asks Zapier which versions it holds rather than inferring from the push, so a release that never arrived is retried on the next push to master, or from the Actions tab. That is also why there is one workflow here and not three. Check the promote step. It passes --yes, without which the CLI waits on a prompt nobody can answer on a runner, and that flag also accepts Zapier's non-blocking pre-check warnings. The repo moves to Node 22, because the pinned Zapier CLI pulls dependencies that refuse to install below Node 20. Zapier still runs this app on Node 18, and will until we move to core 17. Towards INF-3414
eliias
added a commit
that referenced
this pull request
Aug 13, 2026
Publishing this app is manual today, and the repo drifted from what Zapier runs: #99 had to reconstruct 4.10.0 through 4.14.0 out of the published app and back into git. Bump the minor version and write the changelog entry in the same PR as the code. CI fails the PR when code that reaches Zapier changes without that. Merging uploads that version to Zapier and promotes it, so new Zaps get it. Existing Zaps keep the version they were built on, because nothing migrates them. The release workflow asks Zapier which versions it holds rather than inferring from the push, so a release that never arrived is retried on the next push to master, or from the Actions tab. That is also why there is one workflow here and not three. Check the promote step. It passes --yes, without which the CLI waits on a prompt nobody can answer on a runner, and that flag also accepts Zapier's non-blocking pre-check warnings. The repo moves to Node 22, because the Zapier CLI that CI installs pulls dependencies that refuse to install below Node 20. Zapier still runs this app on Node 18, and will until we move to core 17. Towards INF-3414
eliias
added a commit
that referenced
this pull request
Aug 13, 2026
Publishing this app is manual today, and the repo drifted from what Zapier runs: #99 had to reconstruct 4.10.0 through 4.14.0 out of the published app and back into git. Bump the minor version and write the changelog entry in the same PR as the code. CI fails the PR when code that reaches Zapier changes without that. Merging uploads that version to Zapier and promotes it, so new Zaps get it. Existing Zaps keep the version they were built on, because nothing migrates them. The release workflow asks Zapier which versions it holds rather than inferring from the push, so a release that never arrived is retried on the next push to master, or from the Actions tab. That is also why there is one workflow here and not three. Check the promote step. It passes --yes, without which the CLI waits on a prompt nobody can answer on a runner, and that flag also accepts Zapier's non-blocking pre-check warnings. The repo moves to Node 22, because the Zapier CLI that CI installs pulls dependencies that refuse to install below Node 20. Zapier still runs this app on Node 18, and will until we move to core 17. Towards INF-3414
eliias
added a commit
that referenced
this pull request
Aug 13, 2026
Publishing this app is manual today, and the repo drifted from what Zapier runs: #99 had to reconstruct 4.10.0 through 4.14.0 out of the published app and back into git. Bump the minor version and write the changelog entry in the same PR as the code. CI fails the PR when code that reaches Zapier changes without that. Merging uploads that version to Zapier and promotes it, so new Zaps get it. Existing Zaps keep the version they were built on, because nothing migrates them. The release workflow asks Zapier which versions it holds rather than inferring from the push, so a release that never arrived is retried on the next push to master, or from the Actions tab. That is also why there is one workflow here and not three. Check the promote step. It passes --yes, without which the CLI waits on a prompt nobody can answer on a runner, and that flag also accepts Zapier's non-blocking pre-check warnings. The repo moves to Node 22, because the Zapier CLI that CI installs pulls dependencies that refuse to install below Node 20. Zapier still runs this app on Node 18, and will until we move to core 17. Towards INF-3414
eliias
added a commit
that referenced
this pull request
Aug 13, 2026
Publishing this app is manual today, and the repo drifted from what Zapier runs: #99 had to reconstruct 4.10.0 through 4.14.0 out of the published app and back into git. Bump the minor version and write the changelog entry in the same PR as the code. CI fails the PR when code that reaches Zapier changes without that. Merging uploads that version to Zapier and promotes it, so new Zaps get it. Existing Zaps keep the version they were built on, because nothing migrates them. The release workflow asks Zapier which versions it holds rather than inferring from the push, so a release that never arrived is retried on the next push to master, or from the Actions tab. That is also why there is one workflow here and not three. Check the promote step. It passes --yes, without which the CLI waits on a prompt nobody can answer on a runner, and that flag also accepts Zapier's non-blocking pre-check warnings. The repo moves to Node 22, because the Zapier CLI that CI installs pulls dependencies that refuse to install below Node 20. Zapier still runs this app on Node 18, and will until we move to core 17. Towards INF-3414
eliias
added a commit
that referenced
this pull request
Aug 17, 2026
Publishing this app is manual today, and the repo drifted from what Zapier runs: #99 had to reconstruct 4.10.0 through 4.14.0 out of the published app and back into git. Bump the minor version and write the changelog entry in the same PR as the code. CI fails the PR when code that reaches Zapier changes without that. Merging uploads that version to Zapier and promotes it, so new Zaps get it. Existing Zaps keep the version they were built on, because nothing migrates them. The release workflow asks Zapier which versions it holds rather than inferring from the push, so a release that never arrived is retried on the next push to master, or from the Actions tab. That is also why there is one workflow here and not three. Check the promote step. It passes --yes, without which the CLI waits on a prompt nobody can answer on a runner, and that flag also accepts Zapier's non-blocking pre-check warnings. The repo moves to Node 22, because the Zapier CLI that CI installs pulls dependencies that refuse to install below Node 20. Zapier still runs this app on Node 18, and will until we move to core 17. Towards INF-3414
eliias
added a commit
that referenced
this pull request
Aug 17, 2026
Publishing this app is manual today, and the repo drifted from what Zapier runs: #99 had to reconstruct 4.10.0 through 4.14.0 out of the published app and back into git. Bump the minor version and write the changelog entry in the same PR as the code. CI fails the PR when code that reaches Zapier changes without that. Merging uploads that version to Zapier and promotes it, so new Zaps get it. Existing Zaps keep the version they were built on, because nothing migrates them. The release workflow asks Zapier which versions it holds rather than inferring from the push, so a release that never arrived is retried on the next push to master, or from the Actions tab. That is also why there is one workflow here and not three. Check the promote step. It passes --yes, without which the CLI waits on a prompt nobody can answer on a runner, and that flag also accepts Zapier's non-blocking pre-check warnings. The repo moves to Node 22, because the Zapier CLI that CI installs pulls dependencies that refuse to install below Node 20. Zapier still runs this app on Node 18, and will until we move to core 17. Towards INF-3414
eliias
added a commit
that referenced
this pull request
Aug 18, 2026
Publishing this app is manual today, and the repo drifted from what Zapier runs: #99 had to reconstruct 4.10.0 through 4.14.0 out of the published app and back into git. Bump the minor version and write the changelog entry in the same PR as the code. CI fails the PR when code that reaches Zapier changes without that. Merging uploads that version to Zapier and promotes it, so new Zaps get it. Existing Zaps keep the version they were built on, because nothing migrates them. The release workflow asks Zapier which versions it holds rather than inferring from the push, so a release that never arrived is retried on the next push to master, or from the Actions tab. That is also why there is one workflow here and not three. Check the promote step. It passes --yes, without which the CLI waits on a prompt nobody can answer on a runner, and that flag also accepts Zapier's non-blocking pre-check warnings. The repo moves to Node 22, because the Zapier CLI that CI installs pulls dependencies that refuse to install below Node 20. Zapier still runs this app on Node 18, and will until we move to core 17. Towards INF-3414
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Human
What we had deployed in zapier is not the same as what we have in our repo. This aligns it and adds minor sanity check changes (node version, gitignore, prettier config).
Agent
Summary
zapier-platform-coreto 16.5.1.Why
Zapier 4.14.0 is promoted, but
masterstill contains version 4.9.0. The intermediate published versions were not merged into this repository. This PR restores Git as the source for the code that is already running in Zapier.Merging this PR does not deploy or promote a Zapier version. The repository workflow only builds and tests the code.
Known follow-ups
This PR keeps the published behavior separate from later fixes. Follow-up work should:
Validation
yarn install --frozen-lockfileyarn test --runInBand: 4 suites and 16 tests passednpx --no-install prettier --check .git diff --checkyarn zapier-validate: 36 checks passed, 0 failed, 0 publishing warnings, and 28 general warnings