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

All multi-site predeploy hooks trigger on single site deployment #1160

Closed
tooga opened this issue Mar 6, 2019 · 20 comments · Fixed by #1842
Closed

All multi-site predeploy hooks trigger on single site deployment #1160

tooga opened this issue Mar 6, 2019 · 20 comments · Fixed by #1842

Comments

@tooga
Copy link

tooga commented Mar 6, 2019

Environment info

firebase-tools: 6.4.0

Platform: macOS

Test case

For example, following firebase.json runs every hosting targets predeploy hooks even if called with a single hosting deploy target firebase deploy --only hosting:store. After predeploy hooks are run, only the deploy target site is actually deployed.

{
  "hosting": [ 
      {
        "target": "admin",
        "public": "admin/build",
        "predeploy": "./predeploy.sh"
      },
      {
        "target": "store",
        "public": "store/build",
        "predeploy": "./predeploy.sh"
      }
  ]
}

Steps to reproduce

Running firebase deploy --only hosting:deploy-target runs predeploy hooks for all hosting targets in multi-site hosting firebase.json

Expected behavior

Deploying hosting with deploy target should run only the predeploy hooks of the deploy target

Actual behavior

Deploying hosting with deploy target runs all hosting targets predeploy hooks. Still, only the deploy target hosting site is actually deployed

@thechenky
Copy link
Contributor

Hi @tooga I see in your firebase.json file you have the same predeploy hook script for both sites, is that what you wanted? If so I would expect ./predeploy.sh to run on any site deployment. Note that file paths in the firebase.json are relative to the root of your firebase project. See https://firebase.google.com/docs/cli/#hooks for more details.

@thechenky thechenky self-assigned this Mar 6, 2019
@tooga
Copy link
Author

tooga commented Mar 6, 2019

@thechenky the example was a bit simplified, the predeploy script also gets additional parameters: ./predeploy.sh \"$GCLOUD_PROJECT\" \"$RESOURCE_DIR\" and the script itself handles creating a production build for the site that is being deployed.

So now, even if I want to only build and deploy one hosting site (using deploy target), it runs all of the other hosting target predeploy scripts as well, and thus creates also production builds for all of my hosting sites. This doesn't sound like expected behaviour, and I would assume that only the predeploy script defined for the specific hosting target would be run.

@thechenky
Copy link
Contributor

Can you paste the actual command then? It's difficult to debug when I'm not seeing the real code. Please also paste your predeployment script.

@kevinajian kevinajian added the Needs: Author Feedback Issues awaiting author feedback label Mar 6, 2019
@tooga
Copy link
Author

tooga commented Mar 6, 2019

So, the full firebase.json

{
  "hosting": [ 
    {
      "target": "admin",
      "public": "admin/build",
      "headers": [
        {"source": "/service-worker.js", "headers": [{"key": "Cache-Control", "value": "no-cache"}]}
      ],
      "rewrites": [
        {
          "source": "**",
          "destination": "/index.html"
        }
      ],
      "predeploy": "./predeploy.sh \"$GCLOUD_PROJECT\" \"$RESOURCE_DIR\""
    },
    {
      "target": "store",
      "public": "store/build",
      "headers": [
        {"source": "/service-worker.js", "headers": [{"key": "Cache-Control", "value": "no-cache"}]}
      ],
      "rewrites": [
        {
          "source": "**",
          "destination": "/index.html"
        }
      ],
      "predeploy": "./predeploy.sh \"$GCLOUD_PROJECT\" \"$RESOURCE_DIR\""
    }
  ]
}

The predeploy.sh script:

#!/bin/bash

PROJECT_ID=$1
RESOURCE_DIR="$2/.."

if [ "$PROJECT_ID" == "my-dev-project-id" ]; then
    npm --prefix "$RESOURCE_DIR" run build:development
else
    npm --prefix "$RESOURCE_DIR" run build:production
fi

Now on the project root, running firebase deploy --only hosting:store causes both admin and store hosting targets to run predeploy scripts, causing npm run build to run on both targets. After the predeploy scripts have been finished running, only the store hosting site is actually deployed to hosting.

@thechenky
Copy link
Contributor

Hi @tooga thanks for pasting those in, this is much more helpful. How are you setting GCLOUD_PROJECT? Did you verify that executing exactly the command inside predeploy field by itself executes the correct part of the predeploy script? I would also check that the build:development and build:production npm scripts are doing what you expect in your package.json file.

@tooga
Copy link
Author

tooga commented Mar 7, 2019

I think that my custom predeploy scripts or build commands (and if/how they work) are not really relevant here.

This is another simple firebase.json that hopefully makes the issue clear for you:

{
  "hosting": [ 
    {
      "target": "admin",
      "public": "admin/build",
      "predeploy": "echo \"Running ADMIN hosting target predeploy hook\""
    },
    {
      "target": "store",
      "public": "store/build",
      "predeploy": "echo \"Running STORE hosting target predeploy hook\""
    }
  ]
}

So in essence, each predeploy hook of the hosting targets is just printing a command to the CLI. Now, when I run firebase deploy --only hosting:store I assume that the predeploy hook of the STORE target is run, and then it is deployed to Firebase hosting.

What happens now is the following:

tooga: tooga$ firebase deploy --only hosting:store

=== Deploying to 'my-project-app-dev'...

i  deploying hosting
Running command: echo "Running ADMIN hosting target predeploy hook"
Running ADMIN hosting target predeploy hook
✔  hosting[admin]: Finished running predeploy script.
Running command: echo "Running STORE hosting target predeploy hook"
Running STORE hosting target predeploy hook
✔  hosting[store]: Finished running predeploy script.
i  hosting[my-project-store-dev]: beginning deploy...
i  hosting[my-project-store-dev]: found 4 files in store/build
✔  hosting[my-project-store-dev]: file upload complete
i  hosting[my-project-store-dev]: finalizing version...
✔  hosting[my-project-store-dev]: version finalized
i  hosting[my-project-store-dev]: releasing new version...
✔  hosting[my-project-store-dev]: release complete

✔  Deploy complete!

So as you can see, both the ADMIN and STORE predeploy hooks are run. This is not what I expect when I only want to deploy the STORE hosting target.

My .firebaserc file is looking like this:

{
  "projects": {
    "default": "my-project-app-dev",
  },
  "targets": {
    "my-project-app-dev": {
      "hosting": {
        "store": [
          "my-project-store-dev"
        ],
        "admin": [
          "my-project-app-dev"
        ]
      }
    }
  }
}

@google-oss-bot google-oss-bot added Needs: Attention and removed Needs: Author Feedback Issues awaiting author feedback labels Mar 7, 2019
@Memeriaj
Copy link
Contributor

Memeriaj commented Mar 7, 2019

I suspect that I probably did this with PR #1130 (because we we're running lifecycle hook on multi-resource deploys correctly to begin with) but I had thought there was already logic in place to deal with resource specific deploys. I'll take a look.

@Memeriaj
Copy link
Contributor

Memeriaj commented Mar 7, 2019

Aha, so it seems that we currently only deal with --only inside of the deploy process of each product. The only information that the lifecycle hooks are looking at right now are the product targets, but we should really be inspecting the --only string that we're getting back.

@tooga
Copy link
Author

tooga commented Mar 10, 2019

Great that you found the possible issue!

@whollacsek
Copy link

Hello, I'm running into the same issue here, is there an ETA of when the fix will be available?

@Memeriaj
Copy link
Contributor

Sorry about that, for some reason I thought I had already fixed this. I just sent out a PR that should resolve it.

@whollacsek
Copy link

Thanks @Memeriaj

@Memeriaj
Copy link
Contributor

That PR was released as part of 6.7.0 so this should now be fixed if you update the CLI. I'm going to close this issue, but if it isn't working or you find another problem with it please re-open or create a new issue.

@d3dc
Copy link

d3dc commented May 30, 2019

@Memeriaj I just upgraded to firebase-tools@6.10.0 and all my pre-deploy scripts are running for firebase deploy --only hosting:<single> again.

@spitlo
Copy link

spitlo commented Jul 2, 2019

I’m seeing this as well, but for postdeploy hooks. Given a firebase.json like this:

{
  "hosting": [
    {
      "target": "production",
      "public": "public",
      "postdeploy": "echo \"Just deployed My Project to production environment.\""
    },
    {
      "target": "staging",
      "public": "public",
      "postdeploy": "echo \"Just deployed My Project to staging environment.\""
    }
  ]
}

When i run firebase deploy --only hosting:production, I would expect to see only the message "Just deployed My Project to production environment.", but I’m actually getting both messages.

I’m using firebase-tools@7.0.2

@andrioid
Copy link

andrioid commented Aug 8, 2019

@Memeriaj Can we please reopen this? I'm observing this behaviour with firebase-tools@7.2.2

No matter what I write as target-name, it runs pre-deploy for all of the targets. firebase deploy --only hosting:allhailsantaclause will run all targets, even if there is no target by that name.

@duizabojul
Copy link

@Memeriaj Same here on firebase-tools@7.2.2, firebase deploy --only hosting<my-target> will run all targets predeploy and postdeploy scripts.

@bkendall bkendall reopened this Aug 13, 2019
@bkendall
Copy link
Contributor

I'm reopening this and assigning to @Memeriaj to take a look.

@Akahadaka
Copy link

Still an issue in 7.4.0

@enejm
Copy link

enejm commented Sep 3, 2023

This is still an issue in version 12.5.2

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.