This post seems to indicate a better fix than manually setting RUBY_VERSION in netlify.toml:
After deleting the explicit Ruby version pin, I was able to get my site building on the 20.04 image by following these steps:
Under “Site settings > Build & Deploy > Continuous Deployment > Build image selection”, click “Edit Settings” and switch the image to “Ubuntu Focal 20.04 (beta)”.
Under “Site settings > Build & Deploy > Continuous Deployment > Build settings”, click “Editing Settings” and then “Link to a different repository”. Choose the same repo and branch as before.
This reset all the hidden tool version pinnings to the defaults for the 20.04 image, and cut about 20 seconds off the site build time.
Maybe it would make sense to reset the pins when switching images? It would have saved a lot of debugging time.
Yes, it’s possible to do it in bulk, but you’d have to use Netlify API for that. Do note that, we don’t recommend this as there are chances your builds might break and also the API calls would be rate limited for excessive requests. But if you want to do it, you could do it like this (considering you’ve Node.js and npm installed):
Copy the following code in a file named index.js:
const fetch = require('node-fetch')
const NetlifyAPI = require('netlify')
const AccessToken = 'Access Token Here'
const buildImage = '"xenial"' // xenial for default, focal for latest
const sitesToChange = ['netlify-subdomain1', 'netlify-subdomain2'] // leave blank to change all websites using Trusty
function manageChange(site) {
new Promise(resolve => {
fetch(`https://api.netlify.com/api/v1/sites/${site.id}`, {
method: 'PUT',
body: `{"build_image": ${buildImage}}`,
headers: {
Authorization: `Bearer ${AccessToken}`,
'Content-Type': 'application/json'
}
}).then(response => {
if (response.ok) {
return response.json()
} else {
throw response.statusText
}
}).then(() => {
console.log(`Build image for ${site.name} is now set to ${buildImage}`)
resolve(site)
}).catch(error => {
console.log(error)
})
})
}
new NetlifyAPI(AccessToken).listSites().then(sites => {
sites.forEach(site => {
if (sitesToChange.length > 0) {
if (sitesToChange.includes(site.name)) {
manageChange(site)
}
} else if (site.build_image == 'production') {
manageChange(site)
}
})
})
Run npm i netlify node-fetch.
There are two ways you could use this:
Copy each website’s name in the sitesToChange array. If that array has even 1 website, only that would be changed. Rest would be left untouched.
If you wish to change the build image of all websites in your account using Trusty, you should leave that array empty.
You could set your build image to xenial or focal by changing the buildImage constant. Do not remove the " ".
Finally, you need to set the AccessToken constant. You can get its value by going here: Netlify App. Generate a new access token and use its value there. That access token would allow anyone to use API to act on your behalf. So, keep it safe or delete it once done.
Once all this is done, just run node index.js and the script will do its job. It might not be the most optimum code, but it works.
Thanks for sharing your experiences! We’re working on a fix for the issue with Ruby v2.3.6 failing to install.
I’ve also added a few notes to the last section of the migration guide (at the top of this thread) about the fact that versions can be set by default at site creation, and how to reset the defaults by re-linking the site repo.
So why do we set versions for languages a site may not even use? Because it’s not always possible to know for sure that a language isn’t being used, and our priority is to keep builds running as they always have, even if we change a default behind the scenes.
I think that’s perfectly logical. With this being said, I’m guessing most folks will be perfectly fine bumping the default versions if they aren’t using the languages in their builds. (At least I am, N=1).
I believe the observations @jamesh made are a bit more than this though. If (old) default versions are set behind-the-scenes, and the new build image (which now has much more up-to-date defaults) has to install the old versions when building, then does that not add a good bit of time to every build? He noted he shaved a full 20 seconds off his build. If his sites are anything like mine, that’s a huge part of the build time (perhaps even most of it)! Also, if there is ever an issue installing an old version (as with this Ruby issue), then that is actually a point of failure that would not otherwise be there, right?
Scaled across many customers, I think this could end up affecting build server load by a not insignificant amount. I don’t know what the ultimate solution is (old dependencies are always painful like this), but I think the net impact is large enough it might be worth looking into.
I guess what I’m trying to say is that I see a good case for people bumping the defaults when updating build image even if their build isn’t erroring out.
It’s more that this is hidden behaviour. I’d expect anything that I didn’t pin to use the default version of the tool installed into the Docker image. If I wanted something newer, I could manually pin it or wholesale switch to a newer image.
Maybe when you only had the Ubuntu 14.04 based image available for use, it might have made sense to continuously upgrade the default tool versions and downgrade for older customers. If you are providing a choice of images, perhaps it would be better to keep each image stable.
At a very minimum, it would probably be good to undo the pins when switching build images, the same as happens when switching repositories.
Hi, my workplace has a site on Trusty, I’m trying to migrate it to Focal. The build itself runs okay using some of the workarounds above, however, the production site crashes on the client-side due to a “Backbone is not defined” error. This has never occurred before, and the site still builds and runs perfectly on a local server. It uses Node v12.16.1 and Backbone v1.1.2. Any ideas as why this Backbone error would be appearing?
I am reading the email and all of these threads and am 100% lost. I have skills in coding but what you are discussing here and are expecting us to understand is past them. I never set anything up on LInux for my site. I don’t have a clue where to find the respective log you want us to check, nor even if I found it what the action to move forward without interruption is. Why did a very simple platform suddenly require a dual-PhD for use? I’m not trying to be a jerk, I have spent 2 hours trying to understand what this is all about and am 0% closer to resolution.
@SCloudcroft I went ahead and recorded a YouTube tutorial when I re-bumped my versions just now. Perhaps this might help you and any other folks who are a little lost:
Let us know if you still have questions after this.
Hey, thanks Steven. The icon on my profile is a cat ~I’m female. I got to 2:53 Build Image Deployment and my options on my site diverge from yours. I do not have that on my screen anywhere. I don’t have my site on GitHub. Is that why?
If you do not have you site on GitHub, how do you (re-)deploy your site? Do you use Drag and Drop, API Client, or Nelity CLI? (see docs) If your site is not linked to GitHub, then likely you are not building anything, therefore you have nothing you need to do or change in regards the build image.
I’m sure this has been said already, but it bears repeating: why is Ubuntu 16.04 (Xenial) the only platform that is not in beta? It’s been deprecated since April 2021 and there have been two long-term releases (18.04 and 20.04) which have been published since then. This is pretty disappointing.
