Netlify GitHub App permission updates with collaborative Deploy Previews

Features Updates
,
1

Have you received the email with the title “[GitHub] Netlify is requesting updated permissions” and wondered what it’s about? If so, this post is for you!

If you have Netlify’s GitHub App installed on your GitHub account (which is usually true if you have deployed any sites to Netlify with GitHub previously), you received this email due to the permission changes we made for the new collaborative Deploy Previews feature.

(for more information on collaborative deploy previews, please see this post:
Introducing new collaborative Deploy Previews!)

With Netlify’s new collaborative Deploy Previews feature, we are now subscribing to events from GitHub activity to be able to display them in the Netlify Drawer. This keeps the activity between Netlify and GitHub in sync and in real-time.

Additionally, it allows your Netlify team to be able to create new GitHub issues from the Drawer as they review Deploy Previews.

Updating the permissions does not give us write access to your repo, or make any private information publicly available. Nothing changes as far as any other Git or GitHub settings go.

You can learn more about this new feature in here.

:construction_worker_man: May I choose to opt-out for this permission change?

Yes, you may. You can keep using Netlify and deploy sites with GitHub. However, you’ll be missing out on some features of collaborative Deploy Previews, such as real-time sync. You may still use collaborative Deploy Previews with limited features.

Please feel free to ask any questions you may have in the threads.

7 Likes
3

Hi @keiko

I’ve read the announcement ‘Next generation of Deploy Previews’, and the new feature looks very interesting so I’m thinking about giving it a try, but I was wondering, what if for any reason it doesn’t work for me and my team, how could I disable it in the feature if I don’t want to use it anymore?

Thanks
Andrea

2 Likes
4

Hey @amussap,

I’m glad you found the launch interesting! Rather than disable the feature, there are ways to avoid the feature, if you so wish.

Rather than sharing deploy preview URLs – such as https://deploy-preview-8--yoursitename.netlify.app – you could share commit URLs – such as https://f07cdc10ad44cf00088db11d--yoursitename.netlify.app.

The numbered deploy preview URLs contain all of our new collaborative deploy preview tools whereas the status commit URLs do not contain any of this iterative goodness. Both URLs can be found on a particular deploy’s overview.

Deploy_details___www
Deploy_details___www718×256 29 KB

4 Likes
5

Thanks @Scott … my CI pipeline uses the deploy preview URLs, but that’s good to know I could switch my URL to use the commit hash instead. I didn’t know that was an option.

I’m a wolf-pack of one for a lot of my projects hosted on Netlify, so the “collaborative” feature doesn’t give me much value. And the extra assets are messing around with my Lighthouse checks. Is there no other way to opt out of featurepeek/collaborative deploy preview?

2 Likes
6

Thank you, @Scott
but I think it’s not that simple. We’ve configured our project to add the deploy preview link as a comment on PRs. So, I don’t think I can choose which URL to share in this comment. Moreover, I really want to share the deploy preview of the pull request, not of specific commits. So, I’m watching this thread to see what’s the answer for the two people whos already asked how to disable this feature, in case you want to.

Just one more thing - I thought that the feature would only be enabled if, or after, I updated the GitHub app permissions. However, I didn’t click to update this permissions, and I can see the new collaborative deploy preview already available in my pull requests… :thinking:

1 Like
7

Hey both,

Appreciate the feedback!

We felt that there were adequate solutions and alternatives when determining how collaborative deploy previews should look. But rest assured, we’ll take your feedback on board!

As for enabling the feature/permissions – I believe this perms change only actually relates to providing real-time data and not the implementation of CDP as a whole.

One (admittedly drastic) workaround to inhibit the drawer would be to remove the <body> elements from your HTML. Perhaps, as part of your workflow for deploy previews, you could create a build plugin that parses your files for this element and removes it. Similarly, CSPs for deploy previews have been discussed in the other, directly related thread so you may be able to inhibit the drawer this way.

1 Like
8

Hey folks. First off, I love Netlify.

I work on the Google Chrome team and manage projects like Lighthouse. I recently started seeing large regressions in performance for PRs using deploy preview URLs and was surprised to see that this was caused by the new Drawer feature. I don’t believe I’m in the minority of folks relying on Deploy Preview URLs for performance testing in CI and think at minimum, there has to be a way made available to disable this feature.

I totally get why it’s enabled by default (discovery), but users should have the ability to turn it off in they would rather not rewrite their CI pipelines to rely on commit URLs just to workaround this feature. Please consider giving us some control over this as a semi-clean testing environment is a must for CI performance tests…

Cheers,
Addy

2 Likes
9

Hey, @addyosmani! Great to hear from you. I’ve passed this over to our CDP team and we’ll loop back as soon as possible.

1 Like
10

@addyosmani touches on a point that’s been bothering me since the release of the new Netlify Drawer in the deploy previews:

[…] at minimum, there has to be a way made available to disable this feature

My concern isn’t even about performance; it’s purely down to the fact that I didn’t ask for this feature to appear on my deploy previews. And regardless of that it just adds UI cruft and looks out of place. It also forces me to allow for feedback when sharing a deploy preview link, which isn’t always desired.

Fundamentally, it feels rather dodgy to me that a script / iframe is being automatically injected into my sites considering I gave zero permission for it to do so and in many cases don’t require its functionality.

As Addy mentions, I get that you would want to enable this by default (so people can try it out) but the inability to disable it and fully turn it off doesn’t sit right with me.

To put it another way; this feels like a move in the wrong direction and it has genuinely made me more cautious about using Netlify as, aside from the whole forced injection thing, I feel like it is the start of sleep-walking into a Netlify way of doing things that I have less control over.

The reason why I love using Netlify is that it gives me super powers and makes my development experience so much easier, and it does this without getting in the way. This new drawer and feedback system absolutely gets in the way and I have no choice about it.

3 Likes
11

Just also wanted to chime in here as well, in regards to having a way to disable this feature, but also ideally make it programatic via some mechanism like cookies or query string or something at a per user / browser level?

Deploy previews are great not only for collaboration, but also auditing and automation as Addy mentioned. For example, even if I load the deploy preview site in Incognito mode, I still have the drawer prompting me to sign in, and so comes all the assets and requests that come along with that, so there really is no way to get a “clean” / pure evaluation of your site at all now with deploy previews. :frowning:

So hoping there can be a middle ground to be considered so everyone can get what they need out of these two great features coming together.

Thanks Netlify! :slight_smile:

13

The permalink solution does not work for me because I use an identity provider (Auth0) which requires me to specify the urls for the site. This would mean I would need to update my Auth0 settings every single commit.

How do I get around this?

14

I’ve found a temporary workaround, by removing the injected script’s container:

<script>
const s = document.querySelector('[data-netlify-deploy-id]');
s && s.remove();
</script>

To keep this separate from my code I added it in the dashboard as a post processing snippet before </body>.

The browser still downloads the script (1.2kb) but it doesn’t run, so it should have a much smaller perf impact. Since the injected script is marked async, this will (theoretically) always remove it before it runs.

2 Likes
15

Hey @onlyhuman -

i appreciate you sharing your thoughts, and i know that there are others here that agree with you. That said, no one here on the Netlify design or dev teams wants to be told that they are “braindead” and that “they suck”, etc.

Lets turn the volume down on the intensity here.

Your feedback has been shared, you have a workaround for now, we will share an update when we have one. thanks.

4 Likes
18

I’m a long-time user of Netlify and love the product and the whole team behind it.

That said, I’d like to add my voice to those requesting the option to disable this new feature on all deploy preview URLs.

It interferes with performance testing and visual regression testing and for many of us, adds no value if we’re happy with our existing collaboration tools.

The primary value of deploy previews has always been their similarity to production. The extra visuals and JS introduced by the new drawer are variables that make that preview vs. prod comparison less accurate.

So yeah, lots of love to team that worked hard on this, but the ability to opt in/out would be appreciated.

3 Likes
19

thanks for that @ooloth , totally get what you are saying!

I just had a chance to chat with the CDP team and we are pleased to let you know that some of the changes you are asking for have already been released - now is a good time to check in on CDP again.

We’ll have a blog post and a note here in the forums with more information tomorrow, but i thought you’d all want to know we’re definitely listening to the feedback :slight_smile:

1 Like
20

So is there a way to disable the Drawer now? I could not find any blog post related to that.

21

I commend Netlify for having patience, swallowing their pride, and providing you a little grace.

When you make a statement of:

Yes, @Scott I will use the commit URLs from now but can you please share the feedback to your UI designers that they suck. FFS,…

There is really no other way to interrupt your intent to insult.

You seem very passionate about this topic and it sounds like it’s been very frustrating. Just remember there are better and more respectful ways to convey your frustrations without attacking others. I really hope that’s not how your team(s) talk to each other. That would be terribly sad.

If you’ve been a developer this long and have never created a bug or have found patience when that happens, I suggest your write more code. :wink: Besides, if it wasn’t for developers and some bugs, Quality Engineer’s wouldn’t exist. How boring would that be? :thinking: :laughing:

7 Likes
22

thanks for the kind words, @amoline ! We appreciate you and your perspective (and, truly, that of everyone who shares encouragement and critique constructively and respectfully!)

Here is a forums announcement:

blog post (basically the same info):

please let us know how these changes work for you!

4 Likes
23

If I’m not mistaken the latest changes still don’t allow you to fully and permanently disable the drawer and other injected code / iframes. It’s great that there are options that don’t have the drawer on, however that was always the case.

The problem for me still remains that if I want to continue using Deploy Previews (which I love) then I have to accept that there will be an auto-generated link with these features enabled and I simply have no say in the matter. I have no use for the new functionality right now and it doesn’t feel right that I can’t disable it.

I still stand by my original post that not being able to disable this functionality has caused Netlify to get right in the way of my process, when previously Netlify never got in the way.

At risk of being over-dramatic, before this feature I never had a reason to try alternatives to Netlify. Currently I do.