Skip to content
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

Merged
merged 4 commits into from
Nov 17, 2023

Conversation

vincentezw
Copy link
Contributor

@vincentezw vincentezw commented Nov 7, 2023

WHY are these changes introduced?

  • Make more clear when a folder contains uncommited changes prior to deploying.
  • Make it easier to obtain the deployment URL in CI scripts

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 the description (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 the ink components do not lend themselves to output neatly to stderr, to send this output exclusively to stdout.

HOW to test your changes?

Post-merge steps

Checklist

  • I've read the Contributing Guidelines
  • I've considered possible cross-platform impacts (Mac, Linux, Windows)
  • I've added a changeset if this PR contains user-facing or noteworthy changes
  • I've added tests to cover my changes
  • I've added or updated the documentation

@vincentezw vincentezw force-pushed the vez/deploy-check-for-commit branch from 21df3c8 to 0fe25df Compare November 15, 2023 12:50
@vincentezw vincentezw force-pushed the vez/deploy-check-for-commit branch from 0fe25df to 5be8092 Compare November 15, 2023 12:55
@vincentezw vincentezw changed the title [h2 deploy] Check for uncommited changes, add description and force flags [h2 deploy] Check for uncommited changes, output JSON in CI Nov 15, 2023
Copy link
Contributor

@frandiox frandiox left a 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?

packages/cli/src/commands/hydrogen/deploy.ts Outdated Show resolved Hide resolved
packages/cli/src/commands/hydrogen/deploy.ts Outdated Show resolved Hide resolved
packages/cli/src/commands/hydrogen/deploy.ts Outdated Show resolved Hide resolved
@@ -249,6 +249,7 @@ async function runDev({
type: 0,
message:
'MiniOxygen cannot start because the server bundle has not been generated.',
skipOclifErrorHandling: true,
Copy link
Contributor

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? 🤔

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor

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

Copy link
Contributor Author

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',
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🔥

Copy link
Contributor Author

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.

Copy link
Contributor

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 😄

Copy link
Contributor Author

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

.changeset/slimy-sloths-nail.md Outdated Show resolved Hide resolved
Comment on lines +176 to +179
await ensureIsClean(path);
} catch (error) {
if (error instanceof GitDirectoryNotCleanError) {
isCleanGit = false;
Copy link
Contributor

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)?

Copy link
Contributor Author

@vincentezw vincentezw Nov 16, 2023

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.

Copy link
Contributor

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?

Copy link
Contributor Author

@vincentezw vincentezw Nov 17, 2023

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.

'@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.
Copy link
Contributor

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 🤔

Copy link
Contributor Author

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.

Copy link
Contributor

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

Copy link
Contributor

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?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's

@vincentezw
Copy link
Contributor Author

Thanks! When do you think we can start showing deploy as a command?

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.

@vincentezw vincentezw force-pushed the vez/deploy-check-for-commit branch from 4e7bd92 to 38e8706 Compare November 16, 2023 11:03
@vincentezw vincentezw marked this pull request as ready for review November 16, 2023 11:32
@frandiox frandiox merged commit 9ed789d into main Nov 17, 2023
9 checks passed
@frandiox frandiox deleted the vez/deploy-check-for-commit branch November 17, 2023 11:38
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants