Detailed Specifications of Automatic Updates and Version Pinning #12866
Comments
Hiroki-Aoki
changed the title
|
I would also like this clarified ASAP. It's kind of distressing that a tool that could be managed as a devDependency of a node project, using standard semver and npm/yarn/etc tooling, is now in the business of managing itself. I was expecting the migration to v4 to include very few breaking changes, but this discovery will probably require a significant posture change for my team. Ever since an incompatibility in (as I recall) v1.18 led us to have to use different versions of Serverless in different projects (albeit temporarily), we've been happily just including Serverless as a dev dependency of each project we were using it in, and writing little one-liner scripts in package.json to run deploys and teardowns using the locally-installed version. That was such a pleasant (and self-documenting!) experience that we never went back to using global installs. Now we're going to have to reconsider all of that in light of these auto-updates, and step one of that will require a MUCH clearer description of what is actually being updated and when. (And where!) |
I create a new issue regarding question 6 above. #12984 |
|
@skierkowski Sorry to contact you out of the blue. Could you please answer my questions? I really hope your response. (We understand that pinning versions is not recommended by developers of Serverless Framework and that automatically updating versions can bring benefits such as automating security responses, but due to constraints on our team's development process, it is difficult to allow automatic version updates. So we'd like to know the detailed specifications of automatic updates and pinning the version.) |
Issue description
Please tell me the detailed specifications of the automatic updates described in Update Serverless Framework and how to pin a version described in Serverless Framework version pinning.
Questions
serverless updateand every 24 hours (when you run any serverless commands after the updateLastChecked time recorded in~/.serverless/binaries/metadata.jsonhas passed), is that correct? And, are there any other times when automatic updates occur?SERVERLESS_FRAMEWORK_FORCE_UPDATE=trueis set?SERVERLESS_FRAMEWORK_FORCE_UPDATE=falseis set?SERVERLESS_FRAMEWORK_FORCE_UPDATE=falsein the environment variable, but the automatic update did not stop. If you want to fix the version used byserverless deploy, is it only possible to specifyframeworkVersioninserverless.ymlin the way written in Serverless Framework version pinning withframeworkVersioninserverless.yml?frameworkVersioninserverless.yml, is there any way to reference the value in an external file? (I'd like to write the version in one configuration file and reference it from serverless.yml for multiple CloudFormation stacks.)frameworkVersion: '4.4.4'inserverless.ymlreferring to an external file, the Serverless Framework version value output to.serverless/meta.jsonappears to be different.{ "/path/to/serverless": { "versionSfCore": null, "versionFramework": "4.4.6", ... (1) ︙ "composeResolverProviders": { "file": { "instance": { ︙ "serviceConfigFile": { ︙ "frameworkVersion": "4.4.4", ... (2) ︙ "versionSf": "4.4.6", ... (3)Context
frameworkVersioninserverless.ymlis '4.4.4')The text was updated successfully, but these errors were encountered: