For a while now it’s moved to a cross-platform CLI tool that can be installed as a .NET global tool or an available directly from the GitHub releases. It’s a little chonky for the build image, sure, but it gets enough usage that I think the ability to deploy to Netlify make sense. I know it would definitely be great for us at the NUnit project.
I’d love to be able to stop automatic deployment when new commit to production (main) branch has occured while keeping automatic deploy previews builds in pull requests.
At the moment, the only thing to do it by appending [skip ci] or [skip netlify] to commit message. However, this is not ideal solution because simple one can forget it.
There should be some basic automated monitoring. On one of my deployed sites, the automatic certificate renewal had failed with the error “Try again later”. The certificate expired in April and Netlify apparently never tried again. Now that I noticed, I had to click “Renew certificate” to get the site back up.
I am completely new to netlifly, I opened my account yesterday, and have a wish:
tcl scripting language.
It wonders me that also perl is not there, a popular scripting language, but I use tcl.
Another wish would be something like a concise tutorial, but it is perhaps too late for me. I see that you make big efforts for documentation, the AI bot is also very good and helped me a lot, but at the beginning it was not even clear to me what is all this about. A lot of avoidable try and err is necessary. There are a lot of details that should be explicitly said, for example that before the build a copy of the trunk in repo is done, that the creation times are lost and set to the time of copying (problem with git) what makes problems with make, that the build command must create every time the publish directory again, that the publish directory should not be checked in, etc.
After experimenting a little more, I discovered that tcl is there under the name tclsh8.6 —I am glad that it is indeed there, and better, with the version in the name.
I also discovered that cc is also there, as should be in any UNIX system, although not mentioned in [1] below. What I miss is lex (flex) and yacc (byacc) that also belong to every UNIX system and are even in plan9 (with the commentary: “The asteroid to kill this dinosaur is still in orbit”).
These experiments for inspecting the build system by loading in Github a Makefile with commands remind me somehow the old times of the punch cards. Is there a more direct way?
Something that would solve problems for many people would be if deploy previews could be configured depending on the base branch of a pull request. Sure there are workarounds to this, like a custom build script that queries the github API for what branches the PR refers to.
The thing is, netlify already has this information, but it’s not exposed to the user in any way.
My proposal is either, have a BASE_BRANCH environment variable in the deploy-preview context, or even better be able to set configurations like [contexts.deploy-preview.{base branch}].
This would allow to create previews separately for development, staging or production environments so that people can do proper QA at whatever stage they want.
uv is a popular package manager for Python, and it’s really fast. Using uv instead of Poetry in my deploy step saved 15 seconds of CI time. It’s pretty easy to install uv, but it would be great to have it available out-of-the-box. Thanks!
Loving the platform, really.
The only thing that has bugged me is the lack of information about credit usage of the AI Agents, there’s no indication anywhere near the chatbox of the agent, that asking something will cost you credits.