Can not use custom artifact zip in v1.18
See original GitHub issueThis is a Bug Report
Can not use custom artifacts in v1.18
When upgrading to v1.18 of the serverless framework, the artifact tag in the serveless.yml file is ignored. Instead it searches for an artifact named with the service: tag in the yaml file.
For me I had this tag under:
functions:
MyFunction:
package:
artifact: ./lambda.zip
Reverting back to serverless 1.16 and also testing with 1.17 i can see the behaviour I expect with my custom zip specified by the artifact tag being used for deployment.
I’m using nodejs 6.10 on AWS lambda.
Issue Analytics
- State:
- Created 6 years ago
- Reactions:1
- Comments:9 (7 by maintainers)
Top Results From Across the Web
Artifact Publishing disproportionately slow for large number of ...
I am using VSTS with the hosted agent. Artifact publishing is very slow. Cloning the repo, which is much larger than the artifacts...
Read more >Failed to deploy artifacts: Could not find artifact - Stack Overflow
A very simple way to fix this is just by changing/updating the version in the pom.xml file. Suppose 01.16.03 is already used then...
Read more >Getting Maven "Could not transfer artifact from/to releases-ee ...
You get an error message during your Maven build that seems to suggest Maven is looking wrongly for a dependency in Mulesoft Enterprise...
Read more >PublishBuildArtifacts@1 - Publish build artifacts v1 task
Use this task in a build pipeline to publish build artifacts to Azure Pipelines, TFS, or a file share. Syntax. YAML Copy. # ......
Read more >Configure CI/CD pipelines for NodeJs Applications with Azure ...
Supports npmjs.com and authenticated registries like Azure Artifacts. Commands available: CI, Install, Publish, Custom. For custom commands, no need to ...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
BTW: It would be great, if SLS finally would switch to SemVer. Any breaking change should increase the MAJOR number of the package, so that ppl can prepare themselves when switching. Having product management policies interfere with package versioning is a somehow contra-productive approach regarding customer satisfaction (in case of NPM packages and tools). The product itself can still be “v1” which is to be seen more or less virtual (PM side), but the package versions should increase according to semver.
Closing since we’ve pushed quite some fixes regarding this in the past.
Feel free to re-open if this issue wasn’t fixed and is still around.