sanity-io / sanity-plugin-dashboard-widget-netlify Goto Github PK

We are using this plugin for a multi-site setup but have some content that spans across the network of sites. Rather than having to manually publish each site, it would be useful to have the option of clicking a single button to redeploy all of the sites on Netlify.

I'm happy to look at making this modification, but it may take a while as I'll have to fit the change in around actual work.

Cheers all

I'm getting a broken link to the status image and no "Deploy" button.

I was able to follow the documentation for setting up the plugin and connecting my Gatsby site hosted with Netlify in the dashboardConfig file. The point of confusion for me was when I needed to connect the Sanity Studio. I am not hosting my studio on Netlify, but rather Sanity itself so I wasn't clear on what configs to add to this object:

{
  title: 'Sanity Studio',
  apiId: 'xxxxx-yyyy-zzzz-xxxx-yyyyyyyy',
  buildHookId: 'xxxyyyxxxyyyyxxxyyy',
  name: 'sanity-gatsby-blog-20-studio',
}

I took a wild stab and got it right that I didn't need that object and needed to set up a webhook that connected to my netlify build hook I set up. Below is a set by step guide on how to achieve this assuming the user has already created and configured their netlify build hook:

1. Select your studio in the management dashboard
2. Select API > Webhooks > Create Webhook
3. Add a name and use the URL from your netlify build hook as the URL: https://api.netlify.com/build_hooks/XXXXXXX
4. Make sure Create, Update, and Delete are checked under Trigger on
5. Hit save and make a test edit in your Studio to ensure the deploy is triggered.

Hey team,

How do I rename or change production@head to say main@head when I pressed this Deploy button?

Especially for use cases with only one site (which should be the majority?) there is a lot of free space to put to good use:

It would be wonderful to be able to:

• see the history of past deploys
• see what triggered those deploys
• see how long the deploys took
• ..

Anymore ideas? 🙂

It would actually be awesome to also have a usage dashboard widget for Sanity itself.
The same info would be quite useful to pull in from Gatsby Hosting / Cloud.

For a client, I wanted to set up a staging website where he can preview his changes and easily share the URL. I used Netlify branch deploy with the URL https://staging--website.netlify.com.
In the dashboard widget, I registered the production website and the staging website, with each its own build hook.

Everything worked fine, except that both Netlify badges are linked with the production website. I've looked online and it seems that it's not possible to get badges for branch deploys.

It's a pity because this badge is a clever and easy way to show the build status.
Do you have an idea how to show the build status for branch deploys inside the widget?
In Netlify CMS, the user has to click the button "Check for preview" to see if the preview is ready.

Another way would be to provide a setting to at least hide the badge.

Hi. I just started using this plugin and my Netlifty deploys fail because of the conflicting peer dependency @sanity/ui v. 0.36.17

7:52:53 PM: npm ERR! Found: @sanity/[email protected]
7:52:53 PM: npm ERR! node_modules/@sanity/ui
7:52:53 PM: npm ERR!   @sanity/ui@"^0.37.2" from @sanity/[email protected]
7:52:53 PM: npm ERR!   node_modules/@sanity/base
7:52:53 PM: npm ERR!     @sanity/base@"^2.27.2" from the root project
7:52:53 PM: Failed during stage 'building site': Build script returned non-zero exit code: 1 (https://ntl.fyi/exit-code-1)
7:52:53 PM: npm ERR!     peer @sanity/base@"^2.0.0" from @sanity/[email protected]
7:52:53 PM: npm ERR!     node_modules/@sanity/dashboard
7:52:53 PM: npm ERR!       @sanity/dashboard@"^2.29.2" from the root project
7:52:53 PM: npm ERR!     6 more (@sanity/default-layout, @sanity/desk-tool, ...)
7:52:53 PM: npm ERR!   @sanity/ui@"^0.37.2" from @sanity/[email protected]
7:52:53 PM: npm ERR!   node_modules/@sanity/dashboard
7:52:53 PM: npm ERR!     @sanity/dashboard@"^2.29.2" from the root project
7:52:53 PM: npm ERR!   6 more (@sanity/default-layout, @sanity/default-login, ...)
7:52:53 PM: npm ERR!
7:52:53 PM: npm ERR! Could not resolve dependency:
7:52:53 PM: npm ERR! sanity-plugin-dashboard-widget-netlify@"^1.2.1" from the root project
7:52:53 PM: npm ERR!
7:52:53 PM: npm ERR! Conflicting peer dependency: @sanity/[email protected]
7:52:53 PM: npm ERR! node_modules/@sanity/ui
7:52:53 PM: npm ERR!   peer @sanity/ui@"^0.36.12" from [email protected]
7:52:53 PM: npm ERR!   node_modules/sanity-plugin-dashboard-widget-netlify
7:52:53 PM: npm ERR!     sanity-plugin-dashboard-widget-netlify@"^1.2.1" from the root project
7:52:53 PM: npm ERR!
7:52:53 PM: npm ERR! Fix the upstream dependency conflict, or retry
7:52:53 PM: npm ERR! this command with --force, or --legacy-peer-deps
7:52:53 PM: npm ERR! to accept an incorrect (and potentially broken) dependency resolution.
7:52:53 PM: npm ERR!
7:52:53 PM: npm ERR! See /opt/buildhome/.npm/eresolve-report.txt for a full report.
7:52:53 PM: npm ERR! A complete log of this run can be found in:
7:52:53 PM: npm ERR!     /opt/buildhome/.npm/_logs/2022-04-03T18_52_50_009Z-debug-0.log
7:52:53 PM: Error during NPM install
7:52:53 PM: Build was terminated: Build script returned non-zero exit code: 1
7:52:53 PM: Failing build: Failed to build site
7:52:53 PM: Finished processing build request in 9.193144098s

I've been forced to use the --legacy-peer-deps install option to make the site build on my local environment but I don't know of a way to influence the npm install operation on Netlify.

I'm mapping out datasets to Netlify branch deploys and was wondering if there was an easy way to configure this? They're not different apps, so adding a site with the same apiID seems a little goofy. I'd prefer not to trigger a development deploy every time a production article gets updated.

When I see the Netlify build logs from my clients, I see that they triggered multiple builds in a very short time span. For example, one of the websites takes about 2 minutes to build and the logs show something like 12:03, 12:05, 12:07.
I suspect that they click several times (by accident) on the deploy button, which queues up deploy commands.
From my testing, double-clicking the deploy button doesn't trigger two builds. However, after ~10 seconds, it will trigger a new build.

I propose to disable the deploy button right after clicking on it and to enable again at after the build has completed.

What do you think? Have you fellow devs run into a similar issue with clients?

For sites with custom domains, it would be great to be able to override the url prop with a custom domain.

Something along these lines:

{
  name: 'netlify',
  options: {
    title: 'Deployments',
    sites: [
      {
        title: 'Website',
        apiId: 'xxxx-xxxxx',
        buildHookId: 'xxxxxxxxx',
        name: 'website',
        url: 'https://example.com/'
      }
    ]
  }
}

When pushing content changes through git to a site on a multi-site monorepo, all utilising different datasets of a sanity project, Netlify will cancel all sites with no content changes and display the cancelled badge.

On the widget in Sanity, cancelled sites will show the failed badge, is this intentional?

I'd love to fork this as a basis for a similar non-Netlify integration (possibly too specific to be useful to anyone else).

So far as I've spotted, all I have to go on for the license is the package.json MIT declaration.

Please would you consider adding a LICENSE file to this repository? Thank you.

I noticed the following file was expected to be there, but VSCode is outputting the following error:

File '<path to install>/studio/node_modules/sanity-plugin-dashboard-widget-netlify/dist/types/sanity-plugin-dashboard-widget-netlify.d.ts' not found.

Maybe it would be good if there is an option for refreshing data before deploying (for those who are using API CDN).

A screenshot and slightly more detailed description of what this plugin does (or does not do) would be much appreciated as it helps a lot with figuring out whether it's going to be worth the effort to set up.

A few questions I had as an outsider from skimming the readme were:

• Does this show a status or just provide a button to trigger builds?
• Does this show a status badge in the toolbar like the old status badge or do you have to go to the dashboard to check it?
• If I install and set this up does it store any access tokens it needs in shared storage so other users can see it or does each user individually need to authenticate with Netlify like some other plugins?

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Using a curated preset maintained by

Sanity: The Composable Content Cloud

Repository problems

These problems occurred while renovating this repository. View logs.

• WARN: Base branch does not exist - skipping

Pending Approval

These branches will be created by Renovate only once you click their checkbox below.

• chore(deps): update actions/setup-node action to v4 (main)
• chore(deps): update commitlint monorepo to v18 (main) (major) (@commitlint/cli, @commitlint/config-conventional)
• chore(deps): update commitlint monorepo to v19 (main) (major) (@commitlint/cli, @commitlint/config-conventional)
• chore(deps): update dependency @sanity/pkg-utils to v3 (main)
• chore(deps): update dependency @sanity/pkg-utils to v4 (main)
• chore(deps): update dependency @sanity/pkg-utils to v5 (main)
• chore(deps): update dependency @sanity/pkg-utils to v6 (main)
• chore(deps): update dependency @sanity/plugin-kit to v4 (main)
• chore(deps): update dependency @testing-library/jest-dom to v6 (main)
• chore(deps): update dependency @testing-library/react to v14 (main)
• chore(deps): update dependency @testing-library/react to v15 (main)
• chore(deps): update dependency eslint-config-prettier to v9 (main)
• chore(deps): update dependency eslint-plugin-prettier to v5 (main)
• chore(deps): update dependency prettier to v3 (main)
• chore(deps): update dependency rimraf to v4 (main)
• chore(deps): update dependency typescript to v5 (main)
• chore(deps): update linters to v6 (main) (major) (@typescript-eslint/eslint-plugin, @typescript-eslint/parser)
• chore(deps): update linters to v7 (main) (major) (@typescript-eslint/eslint-plugin, @typescript-eslint/parser, eslint-config-sanity)
• fix(deps): Update dependency @sanity/ui to v2 (main)
• chore(deps): lock file maintenance (main)
• 🔐 Create all pending approval PRs at once 🔐

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

• chore(deps): update non-major (main) (@babel/preset-env, @babel/preset-react, @commitlint/cli, @commitlint/config-conventional, @sanity/dashboard, @sanity/pkg-utils, @sanity/plugin-kit, @sanity/semantic-release-preset, @sanity/ui, @testing-library/jest-dom, @types/jest, @types/react, @types/react-dom, @types/styled-components, @typescript-eslint/eslint-plugin, @typescript-eslint/parser, actions/checkout, actions/setup-node, eslint, eslint-config-prettier, eslint-plugin-react, jest, jest-date-mock, jest-environment-jsdom, prettier, prettier-plugin-packagejson, react, react-dom, sanity, styled-components, ts-jest, typescript)
• chore(deps): update actions/checkout action to v4 (main)
• chore(deps): update dependency @sanity/pkg-utils to v2 (main)
• chore(deps): update dependency @sanity/plugin-kit to v3 (main)
• chore(deps): update dependency @sanity/semantic-release-preset to v3 (main)
• chore(deps): update dependency @sanity/semantic-release-preset to v4 (main)
• fix(deps): Update dependency abort-controller to v3 (main)
• fix(deps): Update dependency rxjs to v7 (main)
• fix(deps): Update dependency styled-components to v6 (main)
• Click on this checkbox to rebase all open PRs at once

Detected dependencies

• Check this box to trigger a request for Renovate to run again on this repository