Feature requests - what do you already love, what could be better?

@fool

I’m not sure if we’re on the same page; let me try to explain in a different way what I would like to achieve:

  • I probably wouldn’t use branch deploys - branches are short lived (e.g. hours or a couple days at most) so it probably isn’t worth it
  • All code is merged directly to master branch.
  • Master branch deploys to two (or more? I would probably only use 2 to start, but I have used 3 at various places) different sites:
    • a “stage” website. This website is always deployed/updated when code is merged to master
    • a “prod” website. This website deployment is “locked”, and then can be “unlocked” when we’re ready to “deploy to prod”. We can then lock it again afterwards
  • Both the stage and prod website are managed in a single website config, since really it’s the same repo and even same branch - the only difference is which specific commit has been deployed.

This workflow better matches how trunk-based development generally works, and would improve trunk-based workflows significantly.

Does this help? Let me know if it still doesn’t make sense. Thanks!

I guess I am not understanding what is not possible in that workflow with our existing tooling:

  1. you configure your repo with a netlify.toml that will apply for the 2 sites you link it to. It sets things like environment variables, build command, etc.
  2. on the stage site, you have us build every commit automatically. You can see work in progress at reliable URL’s like feat-1234–mystagesite.netlify.app, and you can see the production build at its URL which you could either set a sitename like “beta.yourdomain.com” for, or use the netlify site directly (https://yourstagingsite.netlify.app).
  3. on the prod site, you have deploys either turned off completely or instead use the locked deploy feature to prevent unwanted publishes. You’d also have builds for all non-production branches turned off, since you don’t need to see a second copy of those builds on the short lived branches on this second site.

Does that sound feasible, and if not, what feels bad about it?

I would love the documentation for Functions to be clearer, especially for those who are new to the concept. There’s a smattering of information on the internet, but it’s hard to tell what is outdated and what doesn’t work. I still don’t know whether to use netlify-build or the build process or what the real difference is. Simple examples would really help - using CRA, using Express, accessing files within a lambda function, etc.

1 Like

@fool

from my earlier post:

so essentially two issues -

  1. not having the ability to change settings for both websites at the same time
  2. the netlify.toml sees both websites as “production” so it’s difficult to have different settings/environment variables since they’re both considered “production”

I think 1) isn’t a big deal, but would be an improvement, but 2) is a big deal and will require me to reconfigure quite a bit to get things to work in this setup. I think it can be done, it’s just not easy nor ideal.

Ah, thanks for clarifying! I don’t have a good workaround for #2 except doing something conditionally in your build script based on site name or site ID, not exactly an easy pattern, since you’d also have to create something for local dev to work. If you only had different branchnames, (staging used a staging branch), you could set branch-specific contexts like [context.master] and [context.staging]. But then we also wouldn’t be talking :slight_smile:

I don’t understand what settings you are making per website, outside of netlify.toml that you need to make in two places - could you elaborate? Perhaps it is possible to set them all there and at least remove the #1 problem.

I don’t understand what settings you are making per website, outside of netlify.toml that you need to make in two places - could you elaborate? Perhaps it is possible to set them all there and at least remove the #1 problem.

Just pretty much anything that is configured through the Netlify website itself, e.g. environment variables, notifications, etc. Nothing major though.

Thanks for walking through this with me. :slight_smile:

environment variables can be configured in netlify.toml (probably only useful if not sensitive; I don’t like committing e.g. my ssh key to the repo!):

https://docs.netlify.com/configure-builds/file-based-configuration/#sample-file shows an example (search for “super secret”).

Glad to talk, sorry we didn’t have a more perfect fit for your workflow!

I am currently using the build ignore feature with a monorepo quite heavily. I also happen to use slack webhooks to notify my team about successful and failed builds.

What I really wish for at this moment, is to differentiate between failed builds and cancelled builds.

I get reports of a failed build in slack every time a build is cancelled, though I see the cancelled tag in netlify itself. I’d love for that to be reflected in the webhook message sent to slack as well.

1 Like

~Request: DNS Zone declared in code repo~

Netlify already has great DNS support, and one makes it very easy to provision SSL certs.
My ask is to augment the Netlify DNS feature to allow us to define our DNS zone records (A, CNAME, ALIAS) as code in our repo. This would allow us to manage our DNS as code.

Hey CRSRDS,

Interesting proposition. May I ask how/why the UI is insufficient for your use case? Not to challenge your request, I’m merely intrigued!

Related to this: I’d love a distinct message type for cancelled builds that can subscribed to, so that we can opt in to notifications for cancelled builds the same way we currently can for successful or failed builds.

Hey @m-schrepel, @lettertwo,

I’ve added both voices to a feature request for this. If/when it’s actioned, we’ll be in touch!

1 Like

I played a bit with asset optimization and security headers/features. I’ve noticed assets optimized are missing subresource integrity. I’d love to have SRI by default on optimized assets.

1 Like

Hey @HyperTesto,

Not the first time we’ve heard this one, either! I’ve added your voice to the open feature request.

1 Like

Hi Luke! Any chance you could publish an update regarding this “Deployable Naming Convention” feat? It’s quite of an stopper for us right now. Thanks!! :slight_smile:

Nothing to report as of yet, @afontcu :frowning: Thanks for checking in!

Hi!

In Asset optimization, I think it could be worth adding an extra step for something like PurgeCSS.

It will navigate through html and css files on the “public” folder containing the generated site, remove unused css and then Bundle CSS will make a bundle.css file and it will be minified by Minify CSS step.

I have Hugo projects and it could be super handy for me (and for the bandwidth consumption, of course)

Hey @aladagemre,

Very interesting scenario! This might be tricky to implement flawlessly, given different methods of calling style sheets. It could be called from a JS file, for example.

We’d perhaps have to navigate the entire publish directory and search for any match to a stylesheet which could be quite timely for larger deploys.

This might be achievable with a Build Plugin; I think you could execute it onBuild which would occur before post-processing but after your build command.

Happy to discuss this further and/or get a feature req raised! Would love the input of others on this one :+1:.

1 Like

It would be awesome if we could have the ability to organize our serverless functions into directories - similar to Vercel functions and like the question that was asked here: Am I able to organise my functions into folders?.

That would be especially nice for large projects that have a lot of serverless functions.

Thank you!

hi @samwell! thanks for writing in. I chatted a little bit about this with some teammates, and we’d love to hear more about what your use case is? Are you looking to have separate js files in actual directories, or? tell us as much as you can about what you are trying to accomplish and why this would be beneficial, so we can evaluate your request a bit more. thanks!