Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Using multiple runtimes and explicit artifact, receive Cannot access package artifact error #281

Open
vectorjohn opened this issue Oct 3, 2022 · 4 comments

Comments

@vectorjohn
Copy link

Hard to describe, but this is when using multiple runtimes, and the other runtime has manual packaging. So we use the package.artifact configuration in serverless.yml, e.g.:

functions:
  hello:
    handler: com.serverless.Handler
    package:
      artifact: target/hello-dev.jar

When I try to package or deploy (e.g. sls deploy), after compiling the typescript it fails with this error:

Error:
Cannot access package artifact at "target/hello-dev.jar" (for "hello"): ENOENT: no such file or directory, access '[REDACTED]/serverless-packaging-bug/.build/target/hello-dev.jar'

This seems to be caused by the code in index.ts in the compileTs function, with this line:
this.serverless.config.servicePath = path.join(this.originalServicePath, BUILD_FOLDER)

Since this doesn't get cleaned up until the very end, it messes with other parts of the serverless build process. That path seems to be where serverless looks for my artifact.

For reference:
Environment: linux, node 14.19.3, framework 3.22.0 (local) 3.22.0v (global), plugin 6.2.2, SDK 4.3.2

This exact serverless.yml used to work in Serverless v2 so perhaps they changed something, but from what I can tell the bug still lies in this plugin.

Here is a full serverless.yml for testing:

service: serverless-packaging-bug

plugins:
  - serverless-plugin-typescript

frameworkVersion: '3'

provider:
  name: aws
  runtime: java8

package:
  individually: true

functions:
  hello:
    handler: com.serverless.Handler
    package:
      artifact: target/hello-dev.jar

  cool:
    runtime: nodejs16.x
    handler: js/cool.handler
    events:
      - http:
          path: cool
          method: get
@vectorjohn
Copy link
Author

I found the real problem, Serverless changed the Serverless.config.servicePath to Serverless.config.serviceDir in version 3. So all the servicePath mangling amounts to naught.

vectorjohn pushed a commit to vectorjohn/serverless-plugin-typescript that referenced this issue Oct 27, 2022
serviceDir and servicePath both are optional so we have to check.
In index.ts, I'm setting both, because according to comments throughout Serverless code, they should actually
be linked. Due to (I think) a bug, they're not. But there may be code that uses either/or, so they should both be set.
Added setter and getter for this, to put that logic in one place.

This doesn't fix serverless#281 yet, but it's a necessary part.
vectorjohn pushed a commit to vectorjohn/serverless-plugin-typescript that referenced this issue Oct 27, 2022
This works at least for our needs. As part of `copyDependencies`, we copy any artifacts
if a function specifies one into .build/.serverless/$(basename artifact) if it is a relative
path.
It seems absolute paths already worked but it makes 0 sense to use those.
vectorjohn pushed a commit to vectorjohn/serverless-plugin-typescript that referenced this issue Oct 27, 2022
@MatejBalantic
Copy link

+1 experiencing this exact problem with mixed project (golang + typescript). @vectorjohn do you recommend any workaround for this problem ?

@dotdave00
Copy link

Has there been any movement or workarounds on this? I've got a project that is traditional java that I'm migrating to nodejs. I'll have both a java artifact and using serverless-plugin-typescript and am experiencing the exact same issue mentioned above.

Rather not hack the code myself unless I need to. Any help is appreciated!

@julbrs
Copy link

julbrs commented Mar 20, 2023

Hi,

We have experienced the exact same issue on our Serverless Framework project. We ended by migrated our stack to SST (https://sst.dev) ; because now it support correctly an API with both Java and TS endpoints... And this is only the top of the iceberg. It's easy to deploy your web app in SST too 🤓

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants