-
Notifications
You must be signed in to change notification settings - Fork 286
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[h2 deploy] Check for uncommited changes, output JSON in CI #1496
Conversation
21df3c8
to
0fe25df
Compare
0fe25df
to
5be8092
Compare
5be8092
to
883fef0
Compare
06791a0
to
9258916
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks!
When do you think we can start showing deploy
as a command?
@@ -249,6 +249,7 @@ async function runDev({ | |||
type: 0, | |||
message: | |||
'MiniOxygen cannot start because the server bundle has not been generated.', | |||
skipOclifErrorHandling: true, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is this needed here and in other commands? 🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems to be a required parameter in cli-kit 3.51.0 for FatalError
https://github.com/Shopify/cli/blob/9d4c411176e13edcf352e4a4d5341aedaf1ee476/packages/cli-kit/src/public/node/error.ts#L27
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh I see! I've seen there's a new renderError
function. Maybe we should be using that instead of renderFatalError
. Not a blocker for this PR though
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think renderFatalError
is still more appropriate in this command, as it accepts an error
and renders it appropriately, whereas renderError
needs a headLine
and body
etc.
@@ -33,6 +33,7 @@ function missingLockfileWarning(shouldExit: boolean) { | |||
|
|||
function multipleLockfilesWarning(lockfiles: Lockfile[], shouldExit: boolean) { | |||
const packageManagers = { | |||
'bun.lockb': 'bun', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🔥
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Lockfile
now includes bun.lockb
(here) so we'd get a Typescript error without it. If we don't want bun, we need to handle the case where the lockfile isn't a key in packageManagers
by adding a check before accessing it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes yes, I understand we need the changes, and I'm quite excited to support Bun actually 😄
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ah ok I misunderstood the burn comment haha
await ensureIsClean(path); | ||
} catch (error) { | ||
if (error instanceof GitDirectoryNotCleanError) { | ||
isCleanGit = false; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Considering we are catching the error, is there any reason to use ensureIsClean()
here instead of directly isClean()
(returns true/false)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's a theoretical possibility the project dir is a non-git directory (i.e. doesn't have the .git
folder). Whilst recommended we don't require a repository directory.
In that scenario isClean()
throws a GitError
(fatal: not a git repository) but we want to proceed, as telling the user to commit in a non-git directory doesn't make sense. With ensureIsClean
we can check for a GitDirectoryNotCleanError
which only appears when the project dir is a Git repository and has uncommitted changes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What about flipping this around? Could we only check if it's clean if it's a git directory?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could, but the only function that cli-kit exports to that extent is ensureInsideGitDirectory. Again that doesn't return a simple boolean, but a OutsideGitDirectoryError
when outside of a Git folder, so I don't think that approach would be any cleaner.
.changeset/slimy-sloths-nail.md
Outdated
'@shopify/cli-hydrogen': minor | ||
--- | ||
|
||
The `deploy` command now displays an error if there are uncommited changes in a project's Git repository. If you'd like to go ahead with the deployment regardless, you can use the new `force` flag. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess it's not a big problem but it might be weird for users to read about h2 deploy
in the changelog when the command is still hidden 🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess in a public repo, it is difficult to hide things. Hopefully we can go public soon.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍🏻 I probably wouldn't add a changeset for something hidden
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah that's what I meant, we don't need to hide the code but it might be confusing if it's part of the release notes but still not usable 🤔
Should we then just remove this changelog for now?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's
Thanks for the review! I don't really have a better answer than "soon". We're still working on some things but I think we're almost there. |
4e7bd92
to
38e8706
Compare
WHY are these changes introduced?
WHAT is this pull request doing?
When using
h2 deploy
this PR checks if the Git folder is "clean" (i.e. has no uncommited changes). When uncommited changes are detected, the deployment is not allowed to proceed unless the new--force
flag is used.When there are uncommited changes, users can use the
metadataDescription
flag to update thedescription
(commit message). If the flag is not used, a default "COMMIT_SHA with additional changes" is used.For development purposes this PR also allows the deployment endpoint to be set using an environment variable.
We also needed to bump the version of cli-kit as the previous version contains a bug in the
ensureGitClean
function.Lastly this PR lets the deploy command create a JSON output file in CI (and adds a
no-json-output
flag to prevent this). This can should be useful in CI environments where merchants want access to the deployment URL in subsequent workflow steps. Unfortunately theink
components do not lend themselves to output neatly tostderr
, to send this output exclusively tostdout
.HOW to test your changes?
Post-merge steps
Checklist