Deployment is very slow (nodeJS with publish profile)

I'm using a workflow file adapted from "build and deploy a Node.js Web app to Azure using publish profile".
(side remark) : I had issues with symbolic links too (see https://github.com/Azure/webapps-deploy/issues/54#issuecomment-694259266)
Upon analysis, it seems that the whole copy of the node_modules folders to the webroot of the webapp takes ages (10-12 minutes for the Azure Webapp deploy step !) It's very inefficient to process and send many little files over network.
=> Shouldn't the final npm install (and npm run build – I'm using typescript) commands be executed on the target machine instead of a github action container ?
IMHO, the workflow should be like this for the "nodeJS with publish profile" scenario :

the github action should only send source files to the targeted runtime machine
npm install, npm run build and npm start should be done on the targeted runtime machine
It's up to the developer to ensure that is app is building correctly before calling azure/webapps-deploy

Related questions :

Also how this Github action is related to Kudu ?
Does it use Kudu behind the scenes ? How ? (bare copy ? zip deploy ?)
If yes, are Kudu capabilities useable ? I.E. .deployment file, deployment hooks, etc.
references : https://github.com/projectkudu/kudu/wiki/Customizing-deployments and https://github.com/projectkudu/kudu/wiki/Deployment-hooks

My deployments are taking 10 minutes and it is slowing us down. How can we improve the situation?

Our deployments are taking over 30 mins!

@0gust1 Sorry for delayed response.
action uses kudu zipdeploy api for deployment with zip file input
https://github.com/projectkudu/kudu/wiki/REST-API#zip-deployment

Any way to speed it up @AmrutaKawade ?

@sfabriece custom deloyment scripts should work.
Do not include node_modules in zip. Instead add .deployment and deploy.cmd / deploy.sh files at root of your repo with npm install command. it will execute npm install on target machine
some examples
https://docs.microsoft.com/en-us/azure/app-service/configure-language-nodejs?pivots=platform-windows#run-gruntbowergulp
https://github.com/projectkudu/kudu/wiki/Deployment-hooks#easiest-way-to-get-started-with-a-custom-deployment-script
https://github.com/projectkudu/kudu/wiki/Custom-Deployment-Script

Thanks @AmrutaKawade !
Ideally, hints could be given in documentations and workflow files (for example: https://github.com/Azure/actions-workflow-samples/blob/master/AppService/node.js-webapp-on-azure.yml), as every nodeJS app will have the same behavior.

@sfabriece you can provide directly zip as a input to action or folder location which will be zipped in action
- name: 'Run Azure webapp deploy action using publish profile credentials'
      uses: azure/webapps-deploy@v2
      with:
        app-name: <app-name>
        publish-profile: ${{ secrets.azureWebAppPublishProfile }}
        package: <provide path of your folder or zip file>

Closing the issue as the question has been addressed and for performance we already have npm install in the sample workflow which optimises the time

Had the same issue, tried with the suggested solution of creating a custom deploy (btw, custom deploy for a standard task?)
but got the following error:
/opt/Kudu/Scripts/starter.sh: line 2: exec: deploy.cmd: not found
/opt/Kudu/Scripts/starter.sh: line 2: exec: deploy.cmd: not found\n/opt/Kudu/Scripts/starter.sh deploy.cmd
so far I wasn't able to solve this issue, so I am falling back to the default inefficient procedure.
I do believe that @0gust1's suggestion is the right approach:
the github action should only send source files to the targeted runtime machine
npm install, npm run build and npm start should be done on the targeted runtime machine
It's up to the developer to ensure that is app is building correctly before calling azure/webapps-deploy
this should be the default w/o any customization needed as it is the standard behavior for node.js apps

Could somebody please explain how this can be solved?
I am using the latest version of the script automatically installed by the Azure portal when using the deployment center. It seems to be running npm install on Github then uploading every file individually. Did anyone find a way to (A) zip them up and unzip them on the target webapp or (B) just do the npm install on the target webapp (although that would stop you from doing any other steps using github actions like testing)?

Seconding this one I am having the same problem and the solutions provided above do not seem to be working. I am using the standard file automatically generated by the Azure portal as well.

@BALAGA-GAYATRI , can you please help here with the above queries? If the solution isn't working, can you please reopen the issue?

Could somebody please explain how this can be solved?
I am using the latest version of the script automatically installed by the Azure portal when using the deployment center. It seems to be running npm install on Github then uploading every file individually. Did anyone find a way to (A) zip them up and unzip them on the target webapp or (B) just do the npm install on the target webapp (although that would stop you from doing any other steps using github actions like testing)?

This is still a problem.  I am trying to deploy a sample angular app and the files are being pushed individually instead of getting packaged together.    The build process is slow as well.

I have a similar problem, but with just simple HTML. It seems that changing a single character in a single file means that the action goes ahead and grabs every file in the site structure to include in the zip rather than the files changed according to the last ref. So, a single character change takes 4-5 minutes to deploy. Setting the package directory as an option is not a functional solution since my devs could adjust any part of the site at any time

+1.  Very slow deployments.

Can someone point to an example on how to setup npm install as post deployment step. Not much luck with google. This was possible with Azure DevOps release task but can't make it work with GitHub action. Tried the suggestion from @AmrutaKawade  without success. looks like the Kudu is skipping .deployment and .deploy.sh files for some reason.
This is written in logs
Kudu sync from: '/tmp/zipdeploy/extracted' to: '/home/site/wwwroot'
Ignoring: .deployment
Ignoring: deploy.sh

Having extremely slow deployment if entire node_modules is packaged (more than 40 min).

I have this same issue. Express server REST API and a React Client front end.
The node_modules would be best built on the server rather than added in the zip deployment.
Though I'm not really seeing much of a resource on how to do that.
Any suggestions?

Same problem here

Since we opened this issue (it's been some time!), we don't use the github action anymore:

we created a dedicated service principal to be used with az cli
we build in the github action and make a zip ourselve
we use the az cli action to deploy
(related?) since this issue opening we also changed our tech stack, we moved from ExpressJS+VueJS to Svelte-kit (with full OS-independent dependencies, on the contrary of our previous tech stack)

Deployment time are now acceptable for us, but we can't right now confirm that the improvements made on the deployment mechanisms described in this issue are working. We hope to have the time to test and confirm.
here the fragment of the github action we use:
note to readers: this works for us, because we have OS independent deps in our code. Technically, in general, it's better to install and build on your runtime env**
     - name: Azure Login
        uses: azure/login@v1
        with:
          creds: ${{steps.vars.outputs.sp_credentials}}
      - uses: actions/checkout@v2
        with:
          fetch-depth: 0
      - uses: actions/setup-node@v2
        with:
          node-version: '14'
      - run: npm ci
      - run: VITE_BUILD_DATE="${{steps.vars.outputs.now}}" npm run build
      - run: zip -r -X Archive_to_deploy.zip node_modules/ node-dist/ package.json
      - name: Deploy
        uses: azure/CLI@v1
        with:
          azcliversion: 2.29.2
          inlineScript: |
            az webapp deployment source config-zip --resource-group "${{steps.vars.outputs.rg_name}}" --name "${{steps.vars.outputs.app_name}}" --src ./Archive_to_deploy.zip

You could even consider runFromPackage. https://docs.microsoft.com/en-us/azure/devops/pipelines/tasks/deploy/azure-rm-web-app-deployment?view=azure-devops#runfromzip-notes
This saved some seconds on my deployment.

It is taking one hour to deploy

@bibekgaihre  I think our content is too large. You should remove unnecessary files.

I came across a solution for this accidentally.
Basically split the workflow into 2 jobs: build & deploy (just like the default workflow template does), but copy between them only the needed files without node_modules.
To do this, I create a zip at the end of the build and unzip it at the beginning of the deploy step.
I had to do this zipping anyway because Github was complaining that I was moving more than 10000 files between the jobs.
https://stackoverflow.com/a/69402502/281252
https://github.com/actions/upload-artifact#too-many-uploads-resulting-in-429-responses
With this workflow, a Node+Angular app takes 1m for build and ~8m for deployment since Oryx/Kudu runs npm install and build again.
Perhaps with a custom build, we might be able to pass it a zip with node_modules and everything built, and just run it without duplicating the build steps... Though there are some node_modules.tar.gz improvements that we might lose
Example workflow
# Docs for the Azure Web Apps Deploy action: https://github.com/Azure/webapps-deploy
# More GitHub Actions for Azure: https://github.com/Azure/actions

name: Build and deploy Node.js app to Azure Web App

on:
  push:
    branches:
      - main
  workflow_dispatch:

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v2

      - name: Set up Node.js version
        uses: actions/setup-node@v2
        with:
          node-version: '16'
          cache: 'npm' # github actions can cache node_modules automatically to speed the build by about ~45s

      - name: npm install, build, and test
        run: |
          npm install
          npm run build --if-present
          npm run test --if-present

      # Zip artifacts to speed things up
      - name: Zip artifact for deployment
        run: zip release.zip ./* -qr -x "node_modules/*" "dist/*"
      # We exclude node_modules and dist because the Azure Oryx/Kudu deploy runs npm install and rebuilds everything anyway...
      # If we zip them we just increase the size of the zip file and it's not needed

      - name: Upload artifact for deployment job
        uses: actions/upload-artifact@v2
        with:
          name: node-app
          path: release.zip

  deploy:
    runs-on: ubuntu-latest
    needs: build
    environment:
      name: 'Production'
      url: ${{ steps.deploy-to-webapp.outputs.webapp-url }}

    steps:
      - name: Download artifact from build job
        uses: actions/download-artifact@v2
        with:
          name: node-app

      - name: Unzip artifact for deployment
        run: |
          unzip -q release.zip
          rm release.zip

      - name: 'Deploy to Azure Web App'
        id: deploy-to-webapp
        uses: azure/webapps-deploy@v2
        with:
          app-name: 'my-app'
          slot-name: 'Production'
          publish-profile: ${{ secrets.AZUREAPPSERVICE_PUBLISHPROFILE_38C3A64C5A4A49F792EA62F5DCBC13ED }}
          package: .

The workflow described above runs in ~10 minutes, out of which the deploy part is the longest.
On my second attempt, I configured the workflow to deploy and run from ZIP, which is much faster - total time ~3 minutes (~1:45s build, ~30s deploy)
Step 1, in Azure configure the app to run from package, and disable the Oryx build (Github actions builds everything anyway)
WEBSITE_RUN_FROM_PACKAGE=1
SCM_DO_BUILD_DURING_DEPLOYMENT=false

Step 2, use this Github workflow that creates a zip after build (including node_modules)
# Docs for the Azure Web Apps Deploy action: https://github.com/Azure/webapps-deploy
# More GitHub Actions for Azure: https://github.com/Azure/actions

name: Build and deploy Node.js app to Azure Web App

on:
  push:
    branches:
      - main
  workflow_dispatch:

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v2

      - name: Set up Node.js version
        uses: actions/setup-node@v2
        with:
          node-version: '16'
          cache: 'npm'

      - name: npm install, build, and test
        run: |
          npm install
          npm run build --if-present
          npm run test:ci --if-present

      # Zip artifacts to speed things up
      - name: Zip artifact for deployment
        run: zip release.zip ./* -qr

      - name: Upload artifact for deployment job
        uses: actions/upload-artifact@v2
        with:
          name: node-app
          path: release.zip

  deploy:
    runs-on: ubuntu-latest
    needs: build
    environment:
      name: 'Production'
      url: ${{ steps.deploy-to-webapp.outputs.webapp-url }}

    steps:
      - name: Download artifact from build job
        uses: actions/download-artifact@v2
        with:
          name: node-app

      - name: 'Deploy to Azure Web App'
        id: deploy-to-webapp
        uses: azure/webapps-deploy@v2
        with:
          app-name: 'my-app'
          slot-name: 'Production'
          publish-profile: ${{ secrets.AZUREAPPSERVICE_PUBLISHPROFILE_38C3A64C5A4A49F792EA62F5DCBC13ED }}
          package: release.zip

@danmana thanks this was extremely helpful... I also had to update the azure startup command to npx serve -s /build to run the app... this is under Configuration/General Settings

/assign

@danmana Were there any other changes you had to make to the app service, yml, etc.? Currently my website is failing to load. Logs reveal "Error: Cannot find module '../scripts/start'".

@trapgar no other relevant changes that I can think of.
Is scripts/start a file that you have defined?
Do you have a "start" script defined in package.json? If so, this is what Oryx will execute.
If you have only the "main" property defined instead, make sure the path to the file is correct.
Check out the Oryx docs to see what commands it uses to run the app  https://github.com/microsoft/Oryx/blob/main/doc/runtimes/nodejs.md#run
Maybe it will help if I tell you all the steps I did:

created a node express app
from VSCode I created an App Service and did a manual deployment to test it worked
I connected the App Service to Github (you can do this from VSCode or from the portal App Service > Deployment Center) - this step generated the default workflow
Made the changes I mentioned above to this workflow

A side note/improvement : before the build, it's better / quicker to do npm ci than npm install
ref: https://docs.npmjs.com/cli/v8/commands/npm-ci

Yes, as @0gust1 mentioned, you can also use npm ci.
When using npm ci you should remove the cache: 'npm' configuration, because it always performs a clean install so caching node_modules only wastes time.
Besides the functional difference between npm ci and npm install, in my experience caching and npm install works just as fast if not faster than npm ci. ymmv

@danmana Thanks for the reply. scripts/start is a script file that is defined by a library. The application is a ReactJS app created using npx create-react-app my-app.
Since this is just for a personal app it's not particularly important that I get this faster than the ~10m per run I have it at now, so I've decided to shelve it until I finish the app itself.

Finally got it working. Build is now ~5m 51s down from ~13m 3s. Still not ideal as my app is pretty small, but I think it's as good as I'm going to get for a Node app given all the packages they usually pull in.
Issue ended being a mix of node_modules unnecessarily included in the zip, package.json & package-lock.json not being included in the zip (Onyx couldn't tell what Node version to use), and finally the zip folder containing a folder of files instead of just the files (release.zip/build/... vs. release.zip/...).
I think the main issue/confusion is that the sample yml provided attempts to copy over the directory contents after npm has already installed all the dependencies. I would suggest that it's updated to not do that.
Since I didn't have any unit tests to run, I no longer run npm install|build|test and skip straight to the zip & deploy. Those with tests could probably just run > rm node_modules or something so it's not zipped & copied.
For those using React my final deployment yml looked like below:
# Docs for the Azure Web Apps Deploy action: https://github.com/Azure/webapps-deploy
# More GitHub Actions for Azure: https://github.com/Azure/actions

name: build & deploy

on:
  push:
    branches:
      - master
  workflow_dispatch:

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v2

      - name: Set up Node.js version
        uses: actions/setup-node@v1
        with:
          node-version: '14.x'

      # Zip artifacts to speed things up
      - name: Zip artifact for deployment
        run: zip -r release.zip *

      - name: Upload artifact for deployment job
        uses: actions/upload-artifact@v2
        with:
          name: node-app
          path: release.zip

  deploy:
    runs-on: ubuntu-latest
    needs: build
    environment:
      name: 'Production'
      url: ${{ steps.deploy-to-webapp.outputs.webapp-url }}

    steps:
      - name: Download artifact from build job
        uses: actions/download-artifact@v2
        with:
          name: node-app

      - name: 'Deploy to Azure Web App'
        id: deploy-to-webapp
        uses: azure/webapps-deploy@v2
        with:
          app-name: 'my-appservice-name'
          slot-name: 'Production'
          publish-profile: ${{ secrets.AZUREAPPSERVICE_PUBLISHPROFILE_XXX }}
          package: release.zip

Any update on this issue? I stopped the process after more than 3hs. I'm using the default file created by Azure Portal.

Hi - the defualt YML file created by azure portal builds file by file which will take longer time based on the no. of files. Can you try with the yml  here : https://github.com/Azure/webapps-deploy#create-azure-web-app-and-deploy-using-github-actions

This is really sort of annoying. We're deploying a Gatsby static App together with an express backend.
The package is about 1 GB (500MB static files and 500MB node_modules).
Deployment takes about 20 minutes on Linux App Service. 😢

This is really sort of annoying. We're deploying a Gatsby static App together with an express backend. The package is about 1 GB (500MB static files and 500MB node_modules). Deployment takes about 20 minutes on Linux App Service. 😢
The only way I can think of is using custom docker images. However, I'd like to avoid this as it hugely adds complexity.

Can you provide your GITHUB workflow file used for deployment?  If you have to many files then the recommendation is to zip and deploy that will expedite the process.

@rabollin I'm using Azure Pipelines and I'm already using zip and ignoring unused files using .artifactignore file.
Here we have a part of my build pipeline script.
          - script: |
              yarn install --frozen-lockfile
              yarn build
            displayName: 'npm install and build for $(slotName)'
          - task: CopyFiles@2
            inputs:
              SourceFolder: $(System.DefaultWorkingDirectory)
              Contents: |
                *
                node_modules/**
                public/**
                routers/**
              TargetFolder: '$(Build.ArtifactStagingDirectory)'
          - publish: '$(Build.ArtifactStagingDirectory)'
            displayName: Publish artifacts
            artifact: WebApp

The build runs in about 5 mins. But the AzureWebApp@1 task for deployment is really slow.
See a snippet of my deploy pipeline:
          deploy:
            steps:
            - checkout: none
            - download: current
              artifact: WebApp
            - task: AzureWebApp@1
              inputs:
                azureSubscription: $(azureSubscription)
                appType: 'webAppLinux'
                appName: $(appName)
                package: '$(Pipeline.Workspace)/WebApp'
                runtimeStack: 'NODE|14-lts'
                startupCommand: 'node server.js'
                deployToSlotOrASE: false
                deploymentMethod: runFromPackage

As far as I can tell this is still an issue for greenfield projects. I am just trying out Azure for the first time today, but I am mostly choosing defaults for everything.

I created a GitHub repo with no code in it.
I created a node web app in Azure, connected to my repo and with a deployment configured (everything default except I changed the default branch to a branch called ci, since I didn't want the app to redeploy for every change to main)
I installed a node framework that comes with a bunch of node_modules out of the box. Hello world works on my local machine. I merge the code to the ci branch and it automatically creates a deploy job.
Deploys now take 15 minutes+, and I can see from the logs that thousands of files from node_modules are being processed.

Interested in what @alexmiddeleer said as well. I have a GitHub Actions file setup and I can see below that the deployment is taking over 20 minutes. There should be some way to trim this time down, no? I tried sending a zip file instead of individual files but that takes over 30 minutes if I use a zip file.
Any suggestions would be appreciated.

I removed npm install step and it run so quickly then. from 60m (fail) to 1m (success)

This is an incredibly poor experience for my first attempt at deploying a project to Azure.
My builds are taking longer than 10 minutes!
Netlify manages this in under 1 minute, on the FREE tier.

Same experience. A single page app with 2 routes and minimal packages is taking >3 hrs to build and deploy on Azure where Netlify takes <1 min. Smh

@MoatezNG could you provide your entire file .yml in copy? Thanks

Takes 30+ min for my deploy step on Azure, just < 5min on DigitalOcean app service.
Sucks that microsoft hasn't provided any guidance here.

@stefanoz-cloud  sure
`name: Build and deploy Node.js app to Azure Web App
on:
push:
branches:
- main
workflow_dispatch:
env:
AZURE_WEBAPP_PACKAGE_PATH: '.' # set this to the path to your web app project, defaults to the repository root
NODE_VERSION: '16.x' # set this to the node version to use
permissions:
contents: read
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: npm install, build
run: |
npm install
npm run build --if-present
- name: Zip artifact for deployment
run: zip release.zip ./* -r
- name: Upload artifact for deployment job
uses: actions/upload-artifact@v3
with:
name: node-app
path: release.zip
deploy:
permissions:
contents: none
runs-on: ubuntu-latest
needs: build
environment:
name: 'Development'
url: ${{ steps.deploy-to-webapp.outputs.webapp-url }}
steps:
  - name: Download artifact from build job
    uses: actions/download-artifact@v3
    with:
      name: node-app

  - name: unzip artifact for deployment
    run: unzip release.zip

  - name: 'Deploy to Azure WebApp'
    id: "id"
    uses: azure/webapps-deploy@v2
    with:
      app-name: 'NAME'
      slot-name: 'SLOT'
      publish-profile: "SECRET"
      package: ${{ env.AZURE_WEBAPP_PACKAGE_PATH }}`

@stefanoz-cloud  sure
` name: Build and deploy Node.js app to Azure Web App
on:
push:
branches:
- main
workflow_dispatch:
env:
AZURE_WEBAPP_PACKAGE_PATH: '.' # set this to the path to your web app project, defaults to the repository root
NODE_VERSION: '16.x' # set this to the node version to use
permissions:
contents: read
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: npm install, build
run: |
npm install
npm run build --if-present
- name: Zip artifact for deployment
run: zip release.zip ./* -r
- name: Upload artifact for deployment job
uses: actions/upload-artifact@v3
with:
name: node-app
path: release.zip
deploy:
permissions:
contents: none
runs-on: ubuntu-latest
needs: build
environment:
name: 'Development'
url: ${{ steps.deploy-to-webapp.outputs.webapp-url }}
steps:
  - name: Download artifact from build job
    uses: actions/download-artifact@v3
    with:
      name: node-app

  - name: unzip artifact for deployment
    run: unzip release.zip

  - name: 'Deploy to Azure WebApp'
    id: 'id'
    uses: azure/webapps-deploy@v2
    with:
      app-name: 'NAME'
      slot-name: 'SLOT'
      publish-profile: 'SECRET'
      package: ${{ env.AZURE_WEBAPP_PACKAGE_PATH }}

`

@stefanoz-cloud  sure
name: Build and deploy Node.js app to Azure Web App

on:
  push:
    branches:
      - main
  workflow_dispatch:

env:
  AZURE_WEBAPP_PACKAGE_PATH: '.' # set this to the path to your web app project, defaults to the repository root
  NODE_VERSION: '16.x' # set this to the node version to use

permissions:
  contents: read

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: npm install, build
        run: |
          npm install
          npm run build --if-present
      - name: Zip artifact for deployment
        run: zip release.zip ./* -r
      - name: Upload artifact for deployment job
        uses: actions/upload-artifact@v3
        with:
          name: node-app
          path: release.zip

  deploy:
    permissions:
      contents: none
    runs-on: ubuntu-latest
    needs: build
    environment:
      name: 'Development'
      url: ${{ steps.deploy-to-webapp.outputs.webapp-url }}
    steps:
      - name: Download artifact from build job
        uses: actions/download-artifact@v3
        with:
          name: node-app
      - name: unzip artifact for deployment
        run: unzip release.zip
      - name: 'Deploy to Azure WebApp'
        id: 'id'
        uses: azure/webapps-deploy@v2
        with:
          app-name: 'NAME'
          slot-name: 'SLOT'
          publish-profile: 'SECRET'
          package: ${{ env.AZURE_WEBAPP_PACKAGE_PATH }}

The deployment is slow when there are many files to deploy.
When uploading a Zip file it's been extracted on the target App service (Linux). This takes a while. I think this is just a serial operation.
We're deploying about ~10.000 static web files (html, js, css) to our App service and it takes ~20min. It's an output of a Gatsby build.
The only way to speed up deployment time is to decrease the artifact size.

I know my comment probably does not add a lot of value, but my strapi app takes about 1.5hrs to deploy. Hopefully microsoft fixes this.

@MoatezNG your answer worked for me. Brought my build and deploy from 2.5 hrs to 20 min. Thank you

Something to add:
While the deployment process takes about 30 mins, after which it crashes with the mysterious "Refer to logs" error, I do already see the changes reflected after about 5ish minutes. No idea why it doesn't just complete, kind of a waste of energy, but at the very least iteration time isn't twice per hour.

Similar issue (https://github.com/Azure/webapps-deploy/issues/229) is going on, we will be fixing this soon.
Closing this issue for now and the progress can be tracked from the mentioned issue.

great to hear, thank you!

In upload artifacts section include only build/ directory
- name: Upload artifact for deployment job         uses: actions/upload-artifact@v2         with:           name: node-app           path: build/

Making the zip file from GitHub build process and doing unzip on the Azure side seems to work much better.
I used the steps as mentioned by  MoatezNG  above.

I significantly reduce my deployment time from 11 minutes to 1 minute by zipping after npm build. Thanks to @MoatezNG.
Before:

After:

I was using Azure Devops to build and package my NextJS app with fully acceptable build times (~1 minute with caching).
Before zipping I removed all files except the ones needed (including not deleting node_modules). I agree that npm install should be run on the target machine but I never managed to get it working using .deployment and deploy.sh files, so I opted for the easy route and adding node_modules to the bundle. This had no effect on deploy times which were still horrendous. It could take 20 minutes or more using the Zip deploy.
However when I changed the WEBSITE_RUN_FROM_PACKAGE application setting to 1 my deploys took 20 seconds. So for everyone banging their heads: go to configuration and set:
WEBSITE_RUN_FROM_PACKAGE=1

A small update (as I originally created the issue...)

We're no longer subject to this problem, as we switched to a Docker-managed deployment model for our project. In this model, the update is much quicker and simpler (we needed containerization for native/OS-dependencies management)
In some cases, the WEBSITE_RUN_FROM_PACKAGE=1 solution is not ideal / won't work: if you rely on mounting in you app folder some folders from Azure Storages. Try it, but your mileage may vary.

Website_Run_From_Package is fine if your app can run from inside the zip file. If you're using Incremental Static Regeneration to build new pages on the fly from data stores, etc. then this won't work for you, and you'll need to unpack the Zip file at one end or the other.

Website_Run_From_Package is fine if your app can run from inside the zip file. If you're using Incremental Static Regeneration to build new pages on the fly from data stores, etc. then this won't work for you, and you'll need to unpack the Zip file at one end or the other.

Well it continues to be an issue to deploy anything other than .NET on Azure

Indeed. Just switched to the AzureWebApp task, increased the memory with NODE_OPTIONS: --max_old_space_size=4096 and now it's failing due to path lengths when trying to unpack and sort the files out:
The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters.```

Not sure who's really at fault here, Windows with its legacy path requirements, or node and npm with it's 90k+ JS files required to run a website...

Hey guys, I wanted to validate @MoatezNG answer as successful.
After you connect your Azure resource to your Github account, you will have a secret and yaml file appear in your respective repo.
You need to access that .yml file and modify it according to @MoatezNG instructions though it might differ for some people. Also remember that indentation is important and will result in errors if done incorrectly.
Here is my new yml file which resulted in deployment in under 4 minutes (remember most of this is automatically generated so you just need to add specific parts):
`# Docs for the Azure Web Apps Deploy action: https://github.com/Azure/webapps-deploy
More GitHub Actions for Azure: https://github.com/Azure/actions
name: Build and deploy Node.js app to Azure Web App -
on:
push:
branches:
- main
workflow_dispatch:
jobs:
build:
runs-on: ubuntu-latest
steps:
  - uses: actions/checkout@v2

  - name: Set up Node.js version
    uses: actions/setup-node@v1
    with:
      node-version: '16.x'

  - name: npm install, build, and test
    run: |
      npm install
      CI=false npm run build --if-present // I did this to skip warnings as errors, remove if you want
      CI=false npm run test --if-present // I did this to skip warnings as errors, remove if you want

  - name: Zip artifact for deployment
    run: zip release.zip ./*

  - name: Upload artifact for deployment job
    uses: actions/upload-artifact@v2
    with:
      name: release.zip
      path: release.zip

deploy:
runs-on: ubuntu-latest
needs: build
environment:
name: 'Production'
url: ${{ steps.deploy-to-webapp.outputs.webapp-url }}
steps:
  - name: Download artifact from build job
    uses: actions/download-artifact@v2
    with:
      name: release.zip
  - name: unzip artifact for deployment
    run: unzip release.zip

  - name: 'Deploy to Azure Web App'
    id: deploy-to-webapp
    uses: azure/webapps-deploy@v2
    with:
      app-name: '<your-app-name-is automatically generated here>'
      slot-name: 'Production'
      publish-profile: ${{ secrets.AZUREAPPSERVICE... is automatically generated here> }}
      package: .`

I was using Azure Devops to build and package my NextJS app with fully acceptable build times (~1 minute with caching). Before zipping I removed all files except the ones needed (including not deleting node_modules). I agree that npm install should be run on the target machine but I never managed to get it working using .deployment and deploy.sh files, so I opted for the easy route and adding node_modules to the bundle. This had no effect on deploy times which were still horrendous. It could take 20 minutes or more using the Zip deploy.
However when I changed the WEBSITE_RUN_FROM_PACKAGE application setting to 1 my deploys took 20 seconds. So for everyone banging their heads: go to configuration and set:
WEBSITE_RUN_FROM_PACKAGE=1

this solve the delay to deployment but adding this,  breaking application and getting this error - code: 'MODULE_NOT_FOUND',

Hi Everyone, we've made changes to the workflow file created by default from the portal. Also, for others who are already using the workflow file you can add 2 steps as mentioned in this comment. Please reply on the other issue #229 if you're still facing the issue.

commenting to keep reference. having a similar situation of ~15min build time even with a zipped directory.
i tried excluding the node_modules folder from the zip and then doing npm install in the startup command. i verified it was targeting the correct directory and that it was correctly installing modules but the apiapp just says there was an error.
may try using a bash script in the /home directory but i cant see why that would work as opposed to a startup command. maybe the order of operations is such that the CI/CD does its build and runs the api.js file then runs the startup command? but still when the api fails wouldnt it retry and then work? why does it continue to fail?

I was using Azure Devops to build and package my NextJS app with fully acceptable build times (~1 minute with caching). Before zipping I removed all files except the ones needed (including not deleting node_modules). I agree that npm install should be run on the target machine but I never managed to get it working using .deployment and deploy.sh files, so I opted for the easy route and adding node_modules to the bundle. This had no effect on deploy times which were still horrendous. It could take 20 minutes or more using the Zip deploy.
However when I changed the WEBSITE_RUN_FROM_PACKAGE application setting to 1 my deploys took 20 seconds. So for everyone banging their heads: go to configuration and set:
WEBSITE_RUN_FROM_PACKAGE=1

this solve the delay to deployment but adding this, breaking application and getting this error - code: 'MODULE_NOT_FOUND',

Did you fixed the issue?

I was using Azure Devops to build and package my NextJS app with fully acceptable build times (~1 minute with caching). Before zipping I removed all files except the ones needed (including not deleting node_modules). I agree that npm install should be run on the target machine but I never managed to get it working using .deployment and deploy.sh files, so I opted for the easy route and adding node_modules to the bundle. This had no effect on deploy times which were still horrendous. It could take 20 minutes or more using the Zip deploy.
However when I changed the WEBSITE_RUN_FROM_PACKAGE application setting to 1 my deploys took 20 seconds. So for everyone banging their heads: go to configuration and set:
WEBSITE_RUN_FROM_PACKAGE=1

this solve the delay to deployment but adding this, breaking application and getting this error - code: 'MODULE_NOT_FOUND',

fixed this issue by changing the zip command to
 - name: Zip artifact for deployment
        run: zip release.zip ./* .next -qr

after it,  the app runs perfect and deploying is fast too

going by the deployment logs in azure, a lot of time taken is azure not being very smart about handling zip deploys, and the workflow staying connected during that. WHen you deploy a zip file it puts it in a /tmp directory, then extracts it to /tmp/zipdeploy/extracted, THEN copies the files over to your destination. it would be a whole lot faster if it just extracted into the target directly

Here is the workflow which runs fast.
name: FE on Azure App Service CI/CD

on:
  workflow_dispatch:
  push:
    branches:
      - main
      - develop
  pull_request:
    types: [opened, synchronize, reopened, closed]
    branches:
      - main
      - develop

env:
  AZURE_WEBAPP_NAME: fe-app-dev
  AZURE_WEBAPP_PACKAGE_PATH: build
  NODE_VERSION: 20.x

permissions:
  contents: read

jobs:
  build-and-deploy:
    name: Build and deploy
    runs-on: ubuntu-latest
    env:
      NODE_ENV: production
      VITE_MY_VAR: ${{ secrets.MY_VAR }}
    environment:
      name: dev
      url: ${{ steps.deploy-to-webapp.outputs.webapp-url }}
    steps:
      - uses: actions/checkout@v4

      - name: Set up Node.js version
        uses: actions/setup-node@v4
        with:
          node-version: ${{ env.NODE_VERSION }}

      - name: yarn install and build
        run: |
          yarn install --frozen-lockfile --production=false
          yarn build

      - name: Deploy to Azure Web App
        id: deploy-to-webapp
        uses: azure/webapps-deploy@v3
        with:
          app-name: ${{ env.AZURE_WEBAPP_NAME }}
          publish-profile: ${{ secrets.AZURE_WEB_APP_PUBLISH_PROFILE }}
          package: ${{ env.AZURE_WEBAPP_PACKAGE_PATH }}

only zip and deploy your dist directory.

on:
  push:
    branches:
      - v2
  workflow_dispatch:

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      - name: Set up Node.js version
        uses: actions/setup-node@v3
        with:
          node-version: '20.x'

      - name: npm install, build, and test
        run: |
          npm install --legacy-peer-deps
          npm run build --if-present

      - name: Zip artifact for deployment
        run: |
          cd dist
          zip -r ../release.zip ./

      - name: Upload artifact for deployment job
        uses: actions/upload-artifact@v4
        with:
          name: node-app
          path: release.zip

  deploy:
    runs-on: ubuntu-latest
    needs: build
    environment:
      name: 'v2-prd'
      url: ${{ steps.deploy-to-webapp.outputs.webapp-url }}

    steps:
      - name: Download artifact from build job
        uses: actions/download-artifact@v4
        with:
          name: node-app

      - name: Unzip artifact for deployment
        run: unzip release.zip

      - name: 'Deploy to Azure Web App'
        id: deploy-to-webapp
        uses: azure/webapps-deploy@v3
        with:
          app-name: 'test-workflow'
          slot-name: 'dev'
          package: .
          publish-profile: ${{ secrets.AZUREAPPSERVICE_PUBLISHPROFILE}}

@sfabriece custom deloyment scripts should work. Do not include node_modules in zip. Instead add .deployment and deploy.cmd / deploy.sh files at root of your repo with npm install command. it will execute npm install on target machine
some examples https://docs.microsoft.com/en-us/azure/app-service/configure-language-nodejs?pivots=platform-windows#run-gruntbowergulp https://github.com/projectkudu/kudu/wiki/Deployment-hooks#easiest-way-to-get-started-with-a-custom-deployment-script https://github.com/projectkudu/kudu/wiki/Custom-Deployment-Script

Or you can deploy include the node_modules only when there is a change to the package.json


Make tifig the default command for the container

so you can run commands like docker run [CONTAINER] --version

solved :)


Removed redundant import

What about older versions of GHC?

Just did some testing, and it looks like anything older than ghc 8.4.1 is broken.

I added some version bounds for backwards compatibility.

@lpsmith
Any thoughts here? This seems pretty simple to me.

Seems ok to me


Turn on Flash during Preview mode Camera4Kivy

I used Camera4Kiby to develop an applicatipon using phone camera to process the catched image, I need the flash during using opencv for image processing.
is there anyway to turn flashlight during camera preview.

Not implemented, but assuming the question is on Android this user hacked it "Although it is not an elegant way" (though it doesn't look bad to me)
https://github.com/Android-for-Python/c4k_qr_example/issues/1#issuecomment-1254498788
Two of you seems enough interest to add this feature to my todo list....
Close?

Thanks a lot, I will give it a try
On Mon, 9 Jan 2023 at 00:11, Android-for-Python @.***>
wrote:

Not implemented, but assuming the question is on Android this user hacked
it "Although it is not an elegant way" (though it doesn't look bad to me)
Android-for-Python/c4k_qr_example#1 (comment)
https://github.com/Android-for-Python/c4k_qr_example/issues/1#issuecomment-1254498788
Two of you seems enough interest to add this feature to my todo list....
Close?
—
Reply to this email directly, view it on GitHub
https://github.com/Android-for-Python/Camera4Kivy/issues/15#issuecomment-1374928198,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ASI4ZGMM2DAERLQFKK7WLHTWRMUORANCNFSM6AAAAAATUN3JAA
.
You are receiving this because you authored the thread.Message ID:
@.***>


StoreCameraMediaOptions does not assign a Name in UWP

Make sure you follow all of the setup directions before posting an issue: https://github.com/jamesmontemagno/MediaPlugin#important-permission-information
If you are creating an issue for a BUG please fill out this information. If you are asking a question or requesting a feature you can delete the sections below.
Failure to fill out this information will result in this issue being closed. If you post a full stack trace in a bug it will be closed, please post it to http://gist.github.com and then post the link here.
Bug Information
Version Number of Plugin: 4.3.0-beta
Device Tested On: Win 10 PC V1809
Simulator Tested On:N/A
Version of VS:  2017 v15.9.12
Version of Xamarin: <IP_ADDRESS>
Versions of other things you are using:
Xamarin Forms <IP_ADDRESS>5677
NetStandard.Library 2.0.3
Microsoft.NETCore.UniversalWindowsPlatform 6.2.8
and many more
Steps to reproduce the Behavior
Run the code to take a picture in UWP.
Expected Behavior
The mediaFile object has a path that ends with the filename used in StoreCameraMediaOptions.
Actual Behavior
The mediaFile object has a path that ends with CCapture...
Code snippet
mediaFile = await CrossMedia.Current.TakePhotoAsync(new StoreCameraMediaOptions
 {
 Name = sfi.FileName,
 PhotoSize = PhotoSize.Custom,
 CustomPhotoSize = set.TakePicturePercentage
 });

 Debug.WriteLine("*** AFTER  CrossMedia.Current.TakePhotoAsync ");
 Debug.WriteLine("File Location:" + mediaFile.Path);
 Debug.WriteLine("Expected Name:" + sfi.FileName);

The output:
*** AFTER  CrossMedia.Current.TakePhotoAsync
File Location:C:\Users\...\LocalCache\CCapture (9).jpg
Expected Name:SomethingElse.jpg

Screenshots
None

Confirming this - photos are unconditionally stored to LocalCache\CCapture.jpg
Additional information:

the Directory property is similarly ignored
the behavior began at version 4.2.0, and 4.3.0
versions <= 4.1.2 honor both properties correctly (so downgrade is a workaround)
tested on Win10 19H1


This Player is not correctly fit on Fragment

I tried to add this player in fragment, But my toolbar is no visible, it covers entire window, Toolbar is partially visible,
Is there any solution for this

fragment_player.xml
<androidx.coordinatorlayout.widget.CoordinatorLayout xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:tools="http://schemas.android.com/tools"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    xmlns:app="http://schemas.android.com/apk/res-auto"
    tools:context=".util.player.PlayerFragment">

    <com.nuveda.taoacademy.util.player.dtpv.DoubleTapPlayerView
        android:id="@+id/video_view"
        android:layout_width="match_parent"
        android:layout_height="match_parent"
        app:show_subtitle_button="false"
        app:dtpv_controller="@id/youtube_overlay" />

</androidx.coordinatorlayout.widget.CoordinatorLayout>

Just Player isn't really designed for use outside a standalone app (as it requests fullscreen, works with insets etc.) so this use isn't supported. I suggest using ExoPlayer directly.


New Branch

Please add the entire question on top as a comment. Check the other codes in the repository for reference.


[Storage] Change dict(str, str) to dict[str, str] for metadata

There are several occurences of dict(str, str) that should be changed to dict[str,str]. Further discussion may be necessary as this change may cause backwards compatibility issues with previous versions of Python.

Will be addressed as part of #28615


[Usage]: Distributed inference with edge case: model fits multiple GPUs, but number of GPUs cannot divide the model size evenly

Your current environment
Collecting environment information...

I have quantized the model to F16 to the gguf format (I know I could/should quantize it further but it's a first test).
I can load this model fine with llama.cpp using text-generation-webui if the context is not too big.
Now I want to test vllm and I'm trying to load that model.
I first started with to load the model with tensor_parallel_size=7 but ran into the #4232 issue.
It has been suggested to use pipeline_parallel_size=7 instead and that's what I'm trying to do now, but it seems that vllm is trying to fit too much on the first GPU and I have quickly a memory error.
The code I'm using right now is simply:
from vllm import LLM

llm = LLM(
    "/home/leszek/.cache/huggingface/hub/models--meta-llama--Meta-Llama-3.1-70B/snapshots/7740ff69081bd553f4879f71eebcc2d6df2fbcb3/Meta-Llama-3.1-70B-F16.gguf",
    tensor_parallel_size=1,
    pipeline_parallel_size=7,
    max_seq_len_to_capture=8192,
)

And as I watch nvidia-smi, I can see that after all my GPUs are loaded with about 575MiB, only the first GPU is starting to fill up, until I get the torch.OutOfMemoryError error.
The output is:
$ python test.py
INFO 09-07 23:30:12 config.py:1647] Downcasting torch.float32 to torch.float16.
WARNING 09-07 23:30:12 config.py:330] gguf quantization is not fully optimized yet. The speed can be slower than non-quantized models.
INFO 09-07 23:30:12 config.py:890] Defaulting to use mp for distributed inference
WARNING 09-07 23:30:12 arg_utils.py:862] Chunked prefill is enabled by default for models with max_model_len > 32K. Currently, chunked prefill might not work with some features or models. If you encounter any issues, please disable chunked prefill by setting --enable-chunked-prefill=False.
INFO 09-07 23:30:12 config.py:999] Chunked prefill is enabled with max_num_batched_tokens=512.
WARNING 09-07 23:30:12 config.py:359] Async output processing can not be enabled with pipeline parallel
INFO 09-07 23:30:12 llm_engine.py:213] Initializing an LLM engine (v0.6.0) with config: model='/home/leszek/.cache/huggingface/hub/models--meta-llama--Meta-Llama-3.1-70B/snapshots/7740ff69081bd553f4879f71eebcc2d6df2fbcb3/Meta-Llama-3.1-70B-F16.gguf', speculative_config=None, tokenizer='/home/leszek/.cache/huggingface/hub/models--meta-llama--Meta-Llama-3.1-70B/snapshots/7740ff69081bd553f4879f71eebcc2d6df2fbcb3/Meta-Llama-3.1-70B-F16.gguf', skip_tokenizer_init=False, tokenizer_mode=auto, revision=None, override_neuron_config=None, rope_scaling=None, rope_theta=None, tokenizer_revision=None, trust_remote_code=False, dtype=torch.float16, max_seq_len=131072, download_dir=None, load_format=LoadFormat.GGUF, tensor_parallel_size=1, pipeline_parallel_size=7, disable_custom_all_reduce=False, quantization=gguf, enforce_eager=False, kv_cache_dtype=auto, quantization_param_path=None, device_config=cuda, decoding_config=DecodingConfig(guided_decoding_backend='outlines'), observability_config=ObservabilityConfig(otlp_traces_endpoint=None, collect_model_forward_time=False, collect_model_execute_time=False), seed=0, served_model_name=/home/leszek/.cache/huggingface/hub/models--meta-llama--Meta-Llama-3.1-70B/snapshots/7740ff69081bd553f4879f71eebcc2d6df2fbcb3/Meta-Llama-3.1-70B-F16.gguf, use_v2_block_manager=False, num_scheduler_steps=1, enable_prefix_caching=False, use_async_output_proc=False)
The tokenizer class you load from this checkpoint is not the same type as the class this function is called from. It may result in unexpected tokenization.
The tokenizer class you load from this checkpoint is 'LlamaTokenizer'.
The class this function is called from is 'PreTrainedTokenizerFast'.
WARNING 09-07 23:30:28 multiproc_gpu_executor.py:56] Reducing Torch parallelism from 16 threads to 1 to avoid unnecessary CPU contention. Set OMP_NUM_THREADS in the external environment to tune this value as needed.
INFO 09-07 23:30:28 custom_cache_manager.py:17] Setting Triton cache manager to: vllm.triton_utils.custom_cache_manager:CustomCacheManager
(VllmWorkerProcess pid=244159) INFO 09-07 23:30:28 multiproc_worker_utils.py:215] Worker ready; awaiting tasks
(VllmWorkerProcess pid=244160) INFO 09-07 23:30:28 multiproc_worker_utils.py:215] Worker ready; awaiting tasks
(VllmWorkerProcess pid=244161) INFO 09-07 23:30:28 multiproc_worker_utils.py:215] Worker ready; awaiting tasks
(VllmWorkerProcess pid=244162) INFO 09-07 23:30:28 multiproc_worker_utils.py:215] Worker ready; awaiting tasks
(VllmWorkerProcess pid=244163) INFO 09-07 23:30:28 multiproc_worker_utils.py:215] Worker ready; awaiting tasks
(VllmWorkerProcess pid=244164) INFO 09-07 23:30:28 multiproc_worker_utils.py:215] Worker ready; awaiting tasks
INFO 09-07 23:30:29 utils.py:977] Found nccl from library libnccl.so.2
(VllmWorkerProcess pid=244159) INFO 09-07 23:30:29 utils.py:977] Found nccl from library libnccl.so.2
INFO 09-07 23:30:29 pynccl.py:63] vLLM is using nccl==2.20.5
(VllmWorkerProcess pid=244159) INFO 09-07 23:30:29 pynccl.py:63] vLLM is using nccl==2.20.5
(VllmWorkerProcess pid=244160) INFO 09-07 23:30:29 utils.py:977] Found nccl from library libnccl.so.2
(VllmWorkerProcess pid=244160) INFO 09-07 23:30:29 pynccl.py:63] vLLM is using nccl==2.20.5
(VllmWorkerProcess pid=244162) INFO 09-07 23:30:29 utils.py:977] Found nccl from library libnccl.so.2
(VllmWorkerProcess pid=244161) INFO 09-07 23:30:29 utils.py:977] Found nccl from library libnccl.so.2
(VllmWorkerProcess pid=244162) INFO 09-07 23:30:29 pynccl.py:63] vLLM is using nccl==2.20.5
(VllmWorkerProcess pid=244161) INFO 09-07 23:30:29 pynccl.py:63] vLLM is using nccl==2.20.5
(VllmWorkerProcess pid=244163) INFO 09-07 23:30:29 utils.py:977] Found nccl from library libnccl.so.2
(VllmWorkerProcess pid=244164) INFO 09-07 23:30:29 utils.py:977] Found nccl from library libnccl.so.2
(VllmWorkerProcess pid=244163) INFO 09-07 23:30:29 pynccl.py:63] vLLM is using nccl==2.20.5
(VllmWorkerProcess pid=244164) INFO 09-07 23:30:29 pynccl.py:63] vLLM is using nccl==2.20.5
INFO 09-07 23:30:29 model_runner.py:915] Starting to load model /home/leszek/.cache/huggingface/hub/models--meta-llama--Meta-Llama-3.1-70B/snapshots/7740ff69081bd553f4879f71eebcc2d6df2fbcb3/Meta-Llama-3.1-70B-F16.gguf...
(VllmWorkerProcess pid=244159) INFO 09-07 23:30:29 model_runner.py:915] Starting to load model /home/leszek/.cache/huggingface/hub/models--meta-llama--Meta-Llama-3.1-70B/snapshots/7740ff69081bd553f4879f71eebcc2d6df2fbcb3/Meta-Llama-3.1-70B-F16.gguf...
(VllmWorkerProcess pid=244160) INFO 09-07 23:30:29 model_runner.py:915] Starting to load model /home/leszek/.cache/huggingface/hub/models--meta-llama--Meta-Llama-3.1-70B/snapshots/7740ff69081bd553f4879f71eebcc2d6df2fbcb3/Meta-Llama-3.1-70B-F16.gguf...
(VllmWorkerProcess pid=244163) INFO 09-07 23:30:29 model_runner.py:915] Starting to load model /home/leszek/.cache/huggingface/hub/models--meta-llama--Meta-Llama-3.1-70B/snapshots/7740ff69081bd553f4879f71eebcc2d6df2fbcb3/Meta-Llama-3.1-70B-F16.gguf...
(VllmWorkerProcess pid=244162) INFO 09-07 23:30:29 model_runner.py:915] Starting to load model /home/leszek/.cache/huggingface/hub/models--meta-llama--Meta-Llama-3.1-70B/snapshots/7740ff69081bd553f4879f71eebcc2d6df2fbcb3/Meta-Llama-3.1-70B-F16.gguf...
(VllmWorkerProcess pid=244161) INFO 09-07 23:30:29 model_runner.py:915] Starting to load model /home/leszek/.cache/huggingface/hub/models--meta-llama--Meta-Llama-3.1-70B/snapshots/7740ff69081bd553f4879f71eebcc2d6df2fbcb3/Meta-Llama-3.1-70B-F16.gguf...
(VllmWorkerProcess pid=244164) INFO 09-07 23:30:29 model_runner.py:915] Starting to load model /home/leszek/.cache/huggingface/hub/models--meta-llama--Meta-Llama-3.1-70B/snapshots/7740ff69081bd553f4879f71eebcc2d6df2fbcb3/Meta-Llama-3.1-70B-F16.gguf...
[rank0]: Traceback (most recent call last):
[rank0]:   File "/home/leszek/tmp/vllmtest/test.py", line 4, in <module>
[rank0]:     llm = LLM(
[rank0]:   File "/home/leszek/miniconda3/envs/vllm/lib/python3.10/site-packages/vllm/entrypoints/llm.py", line 177, in __init__
[rank0]:     self.llm_engine = LLMEngine.from_engine_args(
[rank0]:   File "/home/leszek/miniconda3/envs/vllm/lib/python3.10/site-packages/vllm/engine/llm_engine.py", line 538, in from_engine_args
[rank0]:     engine = cls(
[rank0]:   File "/home/leszek/miniconda3/envs/vllm/lib/python3.10/site-packages/vllm/engine/llm_engine.py", line 305, in __init__
[rank0]:     self.model_executor = executor_class(
[rank0]:   File "/home/leszek/miniconda3/envs/vllm/lib/python3.10/site-packages/vllm/executor/distributed_gpu_executor.py", line 26, in __init__
[rank0]:     super().__init__(*args, **kwargs)
[rank0]:   File "/home/leszek/miniconda3/envs/vllm/lib/python3.10/site-packages/vllm/executor/executor_base.py", line 47, in __init__
[rank0]:     self._init_executor()
[rank0]:   File "/home/leszek/miniconda3/envs/vllm/lib/python3.10/site-packages/vllm/executor/multiproc_gpu_executor.py", line 125, in _init_executor
[rank0]:     self._run_workers("load_model",
[rank0]:   File "/home/leszek/miniconda3/envs/vllm/lib/python3.10/site-packages/vllm/executor/multiproc_gpu_executor.py", line 199, in _run_workers
[rank0]:     driver_worker_output = driver_worker_method(*args, **kwargs)
[rank0]:   File "/home/leszek/miniconda3/envs/vllm/lib/python3.10/site-packages/vllm/worker/worker.py", line 182, in load_model
[rank0]:     self.model_runner.load_model()
[rank0]:   File "/home/leszek/miniconda3/envs/vllm/lib/python3.10/site-packages/vllm/worker/model_runner.py", line 917, in load_model
[rank0]:     self.model = get_model(model_config=self.model_config,
[rank0]:   File "/home/leszek/miniconda3/envs/vllm/lib/python3.10/site-packages/vllm/model_executor/model_loader/__init__.py", line 19, in get_model
[rank0]:     return loader.load_model(model_config=model_config,
[rank0]:   File "/home/leszek/miniconda3/envs/vllm/lib/python3.10/site-packages/vllm/model_executor/model_loader/loader.py", line 1085, in load_model
[rank0]:     model.load_weights(
[rank0]:   File "/home/leszek/miniconda3/envs/vllm/lib/python3.10/site-packages/vllm/model_executor/models/llama.py", line 508, in load_weights
[rank0]:     weight_loader(param, loaded_weight, shard_id)
[rank0]:   File "/home/leszek/miniconda3/envs/vllm/lib/python3.10/site-packages/vllm/model_executor/layers/linear.py", line 555, in weight_loader
[rank0]:     param_data.copy_(loaded_weight)
[rank0]: torch.OutOfMemoryError: CUDA out of memory. Tried to allocate 448.00 MiB. GPU 0 has a total capacity of 23.68 GiB of which 425.81 MiB is free. Including non-PyTorch memory, this process has 23.26 GiB memory in use. Of the allocated memory 22.86 GiB is allocated by PyTorch, and 1.63 MiB is reserved by PyTorch but unallocated. If reserved but unallocated memory is large try setting PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True to avoid fragmentation.  See documentation for Memory Management  (https://pytorch.org/docs/stable/notes/cuda.html#environment-variables)
ERROR 09-07 23:30:55 multiproc_worker_utils.py:120] Worker VllmWorkerProcess pid 244161 died, exit code: -15
INFO 09-07 23:30:55 multiproc_worker_utils.py:123] Killing local vLLM worker processes

Before submitting a new issue...

[X] Make sure you already searched for relevant issues, and asked the chatbot living at the bottom right corner of the documentation page, which can answer lots of frequently asked questions.

pipeline_parallel_size is not supported in LLM, you should use the openai api server instead.

The exact same thing happens if I use vllm serve:
vllm serve log.txt

what does it mean for 70B-F16 ? is it fp16 with 70B model? that would be 140GB already. Your GPUs might not be enough to hold the model.

Yes, the model is quite large at fp16: 131 GiB
I know it does not really make sense to run inference with 16 bits and 8 bits is more than enough.
I'll try to quantize it to 8 bits to see if it works then.
But it works with llama.cpp with less than 21.5GB / GPU with 16 bits with 8192 context.
Here is the llama.cpp output for comparison:
02:15:17-325920 INFO     Loading "Meta-Llama-3.1-70B-F16.gguf"
02:15:17-505805 INFO     llama.cpp weights detected: "models/Meta-Llama-3.1-70B-F16.gguf"
llama_model_loader: loaded meta data with 27 key-value pairs and 724 tensors from models/Meta-Llama-3.1-70B-F16.gguf (version GGUF V3 (latest))
llama_model_loader: Dumping metadata keys/values. Note: KV overrides do not apply in this output.
llama_model_loader: - kv   0:                       general.architecture str              = llama
llama_model_loader: - kv   1:                               general.type str              = model
llama_model_loader: - kv   2:                               general.name str              = 7740ff69081bd553f4879f71eebcc2d6df2fbcb3
llama_model_loader: - kv   3:                           general.finetune str              = 7740ff69081bd553f4879f71eebcc2d6df2fbcb3
llama_model_loader: - kv   4:                         general.size_label str              = 71B
llama_model_loader: - kv   5:                            general.license str              = llama3.1
llama_model_loader: - kv   6:                               general.tags arr[str,6]       = ["facebook", "meta", "pytorch", "llam...
llama_model_loader: - kv   7:                          general.languages arr[str,8]       = ["en", "de", "fr", "it", "pt", "hi", ...
llama_model_loader: - kv   8:                          llama.block_count u32              = 80
llama_model_loader: - kv   9:                       llama.context_length u32              = 131072
llama_model_loader: - kv  10:                     llama.embedding_length u32              = 8192
llama_model_loader: - kv  11:                  llama.feed_forward_length u32              = 28672
llama_model_loader: - kv  12:                 llama.attention.head_count u32              = 64
llama_model_loader: - kv  13:              llama.attention.head_count_kv u32              = 8
llama_model_loader: - kv  14:                       llama.rope.freq_base f32              =<PHONE_NUMBER>00
llama_model_loader: - kv  15:     llama.attention.layer_norm_rms_epsilon f32              = 0.000010
llama_model_loader: - kv  16:                          general.file_type u32              = 1
llama_model_loader: - kv  17:                           llama.vocab_size u32              = 128256
llama_model_loader: - kv  18:                 llama.rope.dimension_count u32              = 128
llama_model_loader: - kv  19:                       tokenizer.ggml.model str              = gpt2
llama_model_loader: - kv  20:                         tokenizer.ggml.pre str              = llama-bpe
llama_model_loader: - kv  21:                      tokenizer.ggml.tokens arr[str,128256]  = ["!", "\"", "#", "$", "%", "&", "'", ...
llama_model_loader: - kv  22:                  tokenizer.ggml.token_type arr[i32,128256]  = [1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, ...
llama_model_loader: - kv  23:                      tokenizer.ggml.merges arr[str,280147]  = ["Ġ Ġ", "Ġ ĠĠĠ", "ĠĠ ĠĠ", "...
llama_model_loader: - kv  24:                tokenizer.ggml.bos_token_id u32              = 128000
llama_model_loader: - kv  25:                tokenizer.ggml.eos_token_id u32              = 128001
llama_model_loader: - kv  26:               general.quantization_version u32              = 2
llama_model_loader: - type  f32:  162 tensors
llama_model_loader: - type  f16:  562 tensors
llm_load_vocab: special tokens cache size = 256
llm_load_vocab: token to piece cache size = 0.7999 MB
llm_load_print_meta: format           = GGUF V3 (latest)
llm_load_print_meta: arch             = llama
llm_load_print_meta: vocab type       = BPE
llm_load_print_meta: n_vocab          = 128256
llm_load_print_meta: n_merges         = 280147
llm_load_print_meta: vocab_only       = 0
llm_load_print_meta: n_ctx_train      = 131072
llm_load_print_meta: n_embd           = 8192
llm_load_print_meta: n_layer          = 80
llm_load_print_meta: n_head           = 64
llm_load_print_meta: n_head_kv        = 8
llm_load_print_meta: n_rot            = 128
llm_load_print_meta: n_swa            = 0
llm_load_print_meta: n_embd_head_k    = 128
llm_load_print_meta: n_embd_head_v    = 128
llm_load_print_meta: n_gqa            = 8
llm_load_print_meta: n_embd_k_gqa     = 1024
llm_load_print_meta: n_embd_v_gqa     = 1024
llm_load_print_meta: f_norm_eps       = 0.0e+00
llm_load_print_meta: f_norm_rms_eps   = 1.0e-05
llm_load_print_meta: f_clamp_kqv      = 0.0e+00
llm_load_print_meta: f_max_alibi_bias = 0.0e+00
llm_load_print_meta: f_logit_scale    = 0.0e+00
llm_load_print_meta: n_ff             = 28672
llm_load_print_meta: n_expert         = 0
llm_load_print_meta: n_expert_used    = 0
llm_load_print_meta: causal attn      = 1
llm_load_print_meta: pooling type     = 0
llm_load_print_meta: rope type        = 0
llm_load_print_meta: rope scaling     = linear
llm_load_print_meta: freq_base_train  = 500000.0
llm_load_print_meta: freq_scale_train = 1
llm_load_print_meta: n_ctx_orig_yarn  = 131072
llm_load_print_meta: rope_finetuned   = unknown
llm_load_print_meta: ssm_d_conv       = 0
llm_load_print_meta: ssm_d_inner      = 0
llm_load_print_meta: ssm_d_state      = 0
llm_load_print_meta: ssm_dt_rank      = 0
llm_load_print_meta: model type       = 70B
llm_load_print_meta: model ftype      = F16
llm_load_print_meta: model params     = 70.55 B
llm_load_print_meta: model size       = 131.42 GiB (16.00 BPW)
llm_load_print_meta: general.name     = 7740ff69081bd553f4879f71eebcc2d6df2fbcb3
llm_load_print_meta: BOS token        = 128000 '<|begin_of_text|>'
llm_load_print_meta: EOS token        = 128001 '<|end_of_text|>'
llm_load_print_meta: LF token         = 128 'Ä'
llm_load_print_meta: EOT token        = 128009 '<|eot_id|>'
llm_load_print_meta: max token length = 256
llm_load_tensors: ggml ctx size =    2.71 MiB
llm_load_tensors: offloading 80 repeating layers to GPU
llm_load_tensors: offloading non-repeating layers to GPU
llm_load_tensors: offloaded 81/81 layers to GPU
llm_load_tensors:        CPU buffer size =  2004.00 MiB
llm_load_tensors:      CUDA0 buffer size = 19584.75 MiB
llm_load_tensors:      CUDA1 buffer size = 19584.75 MiB
llm_load_tensors:      CUDA2 buffer size = 17952.69 MiB
llm_load_tensors:      CUDA3 buffer size = 19584.75 MiB
llm_load_tensors:      CUDA4 buffer size = 17952.69 MiB
llm_load_tensors:      CUDA5 buffer size = 19584.75 MiB
llm_load_tensors:      CUDA6 buffer size = 18324.66 MiB
....................................................................................................
llama_new_context_with_model: n_ctx      = 8192
llama_new_context_with_model: n_batch    = 512
llama_new_context_with_model: n_ubatch   = 512
llama_new_context_with_model: flash_attn = 0
llama_new_context_with_model: freq_base  = 500000.0
llama_new_context_with_model: freq_scale = 1
llama_kv_cache_init:      CUDA0 KV buffer size =   384.00 MiB
llama_kv_cache_init:      CUDA1 KV buffer size =   384.00 MiB
llama_kv_cache_init:      CUDA2 KV buffer size =   352.00 MiB
llama_kv_cache_init:      CUDA3 KV buffer size =   384.00 MiB
llama_kv_cache_init:      CUDA4 KV buffer size =   352.00 MiB
llama_kv_cache_init:      CUDA5 KV buffer size =   384.00 MiB
llama_kv_cache_init:      CUDA6 KV buffer size =   320.00 MiB
llama_new_context_with_model: KV self size  = 2560.00 MiB, K (f16): 1280.00 MiB, V (f16): 1280.00 MiB
llama_new_context_with_model:  CUDA_Host  output buffer size =     0.49 MiB
llama_new_context_with_model: pipeline parallelism enabled (n_copies=4)
llama_new_context_with_model:      CUDA0 compute buffer size =  1216.01 MiB
llama_new_context_with_model:      CUDA1 compute buffer size =  1216.01 MiB
llama_new_context_with_model:      CUDA2 compute buffer size =  1216.01 MiB
llama_new_context_with_model:      CUDA3 compute buffer size =  1216.01 MiB
llama_new_context_with_model:      CUDA4 compute buffer size =  1216.01 MiB
llama_new_context_with_model:      CUDA5 compute buffer size =  1216.01 MiB
llama_new_context_with_model:      CUDA6 compute buffer size =  1216.02 MiB
llama_new_context_with_model:  CUDA_Host compute buffer size =    80.02 MiB
llama_new_context_with_model: graph nodes  = 2566
llama_new_context_with_model: graph splits = 8
AVX = 1 | AVX_VNNI = 0 | AVX2 = 1 | AVX512 = 0 | AVX512_VBMI = 0 | AVX512_VNNI = 0 | AVX512_BF16 = 0 | FMA = 1 | NEON = 0 | SVE = 0 | ARM_FMA = 0 | F16C = 1 | FP16_VA = 0 | WASM_SIMD = 0 | BLAS = 1 | SSE3 = 1 | SSSE3 = 1 | VSX = 0 | MATMUL_INT8 = 0 | LLAMAFILE = 1 |
Model metadata: {'tokenizer.ggml.eos_token_id': '128001', 'general.quantization_version': '2', 'tokenizer.ggml.model': 'gpt2', 'llama.rope.dimension_count': '128', 'llama.vocab_size': '128256', 'general.file_type': '1', 'llama.attention.layer_norm_rms_epsilon': '0.000010', 'general.architecture': 'llama', 'llama.rope.freq_base': '500000.000000', 'tokenizer.ggml.bos_token_id': '128000', 'llama.attention.head_count': '64', 'tokenizer.ggml.pre': 'llama-bpe', 'llama.context_length': '131072', 'general.name': '7740ff69081bd553f4879f71eebcc2d6df2fbcb3', 'general.finetune': '7740ff69081bd553f4879f71eebcc2d6df2fbcb3', 'general.type': 'model', 'general.size_label': '71B', 'general.license': 'llama3.1', 'llama.feed_forward_length': '28672', 'llama.embedding_length': '8192', 'llama.block_count': '80', 'llama.attention.head_count_kv': '8'}
Using fallback chat format: llama-2
02:16:56-962177 INFO     Loaded "Meta-Llama-3.1-70B-F16.gguf" in 99.63 seconds.
02:16:57-007652 INFO     LOADER: "llama.cpp"
02:16:57-008348 INFO     TRUNCATION LENGTH: 8192
02:16:57-009061 INFO     INSTRUCTION TEMPLATE: "Alpaca"

you are hitting an extreme edge case, trying to use 7 GPUs to serve 131GB model. so you need to care about lots of things:

the default gpu_memory_utilization is 0.9 . You might need to increase it to 0.95 or 0.98
the default partition of pipeline parallel is to evenly partition the layers, but the first gpu also needs to store the word embedding, while the last gpu needs to store the lm head. if you want to balance the gpu memory pressure, you can set the environment variable VLLM_PP_LAYER_PARTITION to the partition you want, e.g. set a small value for the first and the last. see https://github.com/vllm-project/vllm/blob/main/tests/distributed/test_pipeline_partition.py for example to see how to set it.
the ultimate solution is to offload some weights to cpu, at the cost of slow execution. see the --cpu-offload-gb section in https://docs.vllm.ai/en/latest/models/engine_args.html

Thanks for all your clarifications.
I've quantized the model to Q6_K to reduce the size to a more reasonable 54GiB and now it is working correctly with vllm, spreading the load on all the gpus.
But vllm still uses way more VRAM than llama.cpp just for loading the model. I've compared using nvidia-smi to check the VRAM used just after the model has been loaded.
memory usage for each GPU in MiB
vllm
16645
15355
15355
15355
15355
15355
20459
Total: 113879 MiB
llama.cpp
9897
9897
9195
9897
9195
9897
9317
Total: 67295 MiB
So vllm uses ~70% more VRAM than llama.cpp just after loading the model, and the load is much more balanced between the gpus by default. Using your VLLM_PP_LAYER_PARTITION might equalize the situation a bit.
Closing this issue as it now works.

I think vllm and llama.cpp have different purpose. vllm aims for high throughput serving, and will take as much memory as possible.
if you want vllm to take less memory, adjust gpu_memory_utilization .


[MAUI] Padding on UnderlinedTabItem leads to inexplicable behavior

Platform:

OS: [Android]
Device: [Samsung S22 Ultra (Android 14) and Pixel 6 (Android 15 Preview)]
Sdk vervion: [Android SDK 34]
MAUI: [8.0.300]

Describe the bug
When adding Padding to UnderlinedTabItem in TabHostView (TabType="Scrollable"), tabs starting to move and grow. And this does not happen on all devices.
To Reproduce
Steps to reproduce the behavior:

I have used MauiSample to reproduce this: https://github.com/roubachof/Sharpnado.Tabs/blob/main/MauiSample/
Add Padding="5" to any tabs:UnderlinedTabItem tag (on Views/TabM.xaml)
See error

Video
https://github.com/roubachof/Sharpnado.Tabs/assets/36166982/f4606cb9-b847-4cda-9d3f-8dcc00f29573

I found a workaround: adding Margin="1, 0" fixes this behavior. With 1px margin you can get padding work as expected.
But i still think it is a problem.

Yeah I repro that, I guess it's a maui bug with grid and the Auto size...

https://github.com/dotnet/maui/issues/25499


ERROR:"ReferenceError: require is not defined" while using moment on Log Agent

I am trying to modify the value of @timestamp in my logs to an epoch (UNIX format) but when i use moment in my pattern.yml I get the below error with logagent.
ERROR:"ReferenceError: require is not defined"
npm -v : 3.10.10
sudo npm i moment -g:
/usr/lib
âââ<EMAIL_ADDRESS>Code snippet of transform from my yml:
transform: !!js/function >
function (p) {
moment = require('moment')
p['@timestamp'] = moment().valueOf()
}
Am i missing some package or not doing this right?

Can Anyone Help on this? More information if required:
MACHINE: uname -a : Linux raova02-S7229 3.10.0-327.el7.x86_64 #1 SMP Thu Oct 29 17:29:29 EDT 2015 x86_64 x86_64 x86_64 GNU/Linux
STEPS followed for installation:
NODE JS:
curl --silent --location https://rpm.nodesource.com/setup_6.x | sudo bash -
sudo yum -y install nodejs
LogAgent:
Install Logagent npm package
sudo npm i -g @sematext/logagent
Any Help would be appreciated.
-Vaibhav

Hi @raovaibhav,
could you please provide us a complete yml file and command you use to instruct logagent ?
I'll check on it asp
Regards

Thanks for the response @fbalicchia
Heres the info requested:
Command to test : cat /opt/apache_access_new.txt | /usr/bin/logagent -p -n myapp -f /opt/new.yml --verbose
Usually i use the systemctl service only to start LA and post to ES but using the above commands to test the patterns/fields
Content of logfile (apache_access_new.txt)
<IP_ADDRESS> - - [12/Oct/2017:10:00:07 -0700] "GET /servicedesk/web/jsp/apps/OrderStatus.jsp?orderid=12PPHUA2321 HTTP/1.1" 200 75 0.007
<IP_ADDRESS> - - [12/Oct/2017:10:00:08 -0700] "GET /servicedesk/web/jsp/apps/OrderStatus.jsp?orderid=12PPHUA2321 HTTP/1.1" 200 75 0.007
<IP_ADDRESS> - - [12/Oct/2017:10:00:09 -0700] "GET /servicedesk/web/jsp/apps/OrderStatus.jsp?orderid=12PPHUA2321 HTTP/1.1" 200 75 0.007
Pattern File:
[root@raova02-S7229 opt]# cat new.yml
Sensitive data can be replaced with a hashcode (sha1)
it applies to fields matching the field names by a regular expression
Note: this function is not optimized (yet) and might take 10-15% of performance
#autohash: !!js/regexp /user|password|email|credit_card_number|payment_info/i
autohash: false
set this to false when autohash fields
the original line might include sensitive data!
originalLine: false
suppress: false
activate GeoIP lookup
geoIP: true
Logagent updates GeoIP DB files automatically
pls. note write access to this directory is required
maxmindDbDir: /tmp/
debug: false
The global transform function is called for each parsed line.
A good place to do add global fields, custom date processing, or special parsers.
globalTransform: !!js/function >
function (source, parsedObject) {
parsedObject.tenant_id = "Test"
parsedObject.logtype = parsedObject._type
parsedObject.file = parsedObject.logSource
parsedObject._type = "data"
//delete parsedObject._type
delete parsedObject.logSource
//delete parsedObject['@timestamp']
}
patterns:

APACHE  Web Logs

sourceName: !!js/regexp /.apache.|.myapp./
match:
# Common Log Format
- regex:        !!js/regexp /([0-9a-f.:]+)\s+(-|.+?)\s+(-|.+?)\s+[([0-9]{2}/[a-z]{3}/[0-9]{4}:[0-9]{2}:[0-9]{2}:[0-9]{2}[^]])] "(\S+?)\s(\S?)\s{0,1}(\S+?)" ([0-9|-]+) ([0-9|-]+) ([0-9|.-]+)/i
type: apache_access
fields:       [clientip,remote_id,user,ts,http_method,request,http_version,response_code,bytes,response_time]
dateFormat: DD/MMM/YYYY:HH:mm:ss ZZ
# lookup geoip info for the field client_ip
geoIP: client_ip
transform: !!js/function >
function (p) {
moment = require('moment')
p['@timestamp'] = moment().valueOf()
//p['@timestamp'] = "1509527570570"
}

Hi,
I've reproduce the behaviour, moment is already present as Logagent dependency
dependency
but as you can saw it can't be found at runtime cause is not in scope.
I try figure out a way to define it with JS-YAML but.... Sorry I can’t find
a solution

Hi @fbalicchia ,
Actually it states it the example pattern files https://github.com/sematext/logagent-js/blob/69fc9456929733de6c01c0dab159dd39f0cb684f/patterns.yml#L62 about moment being supported as a JS-YAML configuration?
Also i have seen many suggestions on using moments in the conf file to parse date in logagents github threads.
So, I am guessing this is supported but is not achievable by the way i am doing this? I can follow any other method for downloading and running LA if it will make the "moments" configuration work.
Let me know if you know of some other mechanism for LA to be able to include moment at runtime?
BR,

@raovaibhav Note that JS-YAML limits the JS function for security reasons. For the globalTransform we bound moment to the function - you can use moment via this.moment. Currently, there is no such binding for patterns 'transform' functions as far I know.
We will check if we could provide general "require" in transform functions - for complex actions you could always create e.g. output filter plugins as separate npm packages.
In your specific case you could convert the @timestamp Date field  with the Date function "getTime" and divide the value by 1000 to get seconds:
parsed['@timestamp'] = parsed['@timestamp'].getTime()/1000

@raovaibhav Although require is undefined on global scope it is still defined on process.mainModule so you could require moment like so: const moment = process.mainModule.require('moment');

Thanks @Faleij .  Can you confirm if that works for you, @raovaibhav ?

Thanks @megastef and @Faleij , both the solutions work perfect.
//Best Regards


Ability to require local files, -r ./local_file

-r option can already load local node_modules, it be cool if it could load local files as well.
mocha test.js -r ./utils

... gonna get it to work with coffee-script next...

currently d177952 doesn't default to .js, example
$> ls
spec.coffee
tools.js
tools.coffee

$> mocha spec.coffee -r ./tools

// Loads tools.coffee, but should load tools.js

also... might be good to add support for absolute coffee-script file modules 0ca6ca8
$> mocha spec.coffee -r /home/qv/test.coffee

+1

Maybe I should I add some unit tests...

man you coffeescript people :p you should just compile your CS to js first

I think we can do the other part of this better with the path module though I'll take a look at this later


Datepicker 0.20 doesn't work in react-bootstrap's modal

0.19 was fine
There is no error in console...

Probably a z-index issue; try finding the datepicker__tether-element at the end of the DOM when you click the picker, and increasing its z-index until it's visible.

yeah that's, thank you!

Woot!


Fail early on missing encoding profile

If the encoding profile is missing on a remote node (opencast-worker), the workflow failed with a misleading exception. This PR introduces an exception and fails early instead of ignoring a missing profile and failing later.

[x] have a concise title
[x] close an accompanying issue if one exists
[x] be against the correct branch
[x] include migration scripts and documentation, if appropriate
[x] pass automated tests
[x] have a clean commit history
[x] have proper commit messages (title and body) for all commits

I tried, works as expected, but I don't understand something.
Should fail at the beginning of the task, or at the start of the Encode WoH?


NullPointerException in OkHttpInspectorResponse.connectionId()

I'm getting the following crash once Chrome is connected to the app and the app tries to do an HTTP request:
09-02 06:00:27.044  28152-28197/... E/AndroidRuntime﹕ FATAL EXCEPTION: OkHttp Dispatcher
    Process: ..., PID: 28152
    java.lang.NullPointerException: Attempt to invoke virtual method 'int java.lang.Object.hashCode()' on a null object reference
            at com.facebook.stetho.okhttp.StethoInterceptor$OkHttpInspectorResponse.connectionId(StethoInterceptor.java:228)
            at com.facebook.stetho.inspector.network.NetworkEventReporterImpl.responseHeadersReceived(NetworkEventReporterImpl.java:144)
            at com.facebook.stetho.okhttp.StethoInterceptor.intercept(StethoInterceptor.java:72)
            at com.squareup.okhttp.Call$ApplicationInterceptorChain.proceed(Call.java:221)
            at com.squareup.okhttp.Call.getResponseWithInterceptorChain(Call.java:195)
            at com.squareup.okhttp.Call.access$100(Call.java:34)
            at com.squareup.okhttp.Call$AsyncCall.execute(Call.java:162)
            at com.squareup.okhttp.internal.NamedRunnable.run(NamedRunnable.java:33)
            at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1112)
            at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:587)
            at java.lang.Thread.run(Thread.java:818)

I'm using the following lines in my build.gradle file:
    debugCompile 'com.facebook.stetho:stetho:1.1.1'
    compile 'com.facebook.stetho:stetho-okhttp:1.1.1'

    compile 'com.squareup.okhttp:okhttp:2.5.0'

It's possible you accidentally used okHttpClient.interceptors().add(...) instead of okHttp.networkInterceptors().add(...).  An NPE is probably the wrong response out of Stetho, but it can't work all the same because interceptors provide very different kinds of information than the network interceptors.

That is indeed possible. I was not aware that there was more than one kind of interceptors in OkHttp...

@jasta I had the same issue. Thanks for clarifying!

@jasta As a safety measure, would it be possible to add a fail-fast null-check at StethoInterceptor.intercept or in OkHttpInspectorResponse constructor and throw a useful exception pointing this out?

I had the same problem, 2 years later, found this issue and solved it by using addNetworkInterceptor. It would be great if the Exception message suggested this.


🔴 Ecosystem Project Idea: ATST Data Duplicator

What is an Ecosystem Project Idea?
An Ecosystem Project Idea is an idea for a project that someone could build within the Optimism ecosystem. As opposed to an Ecosystem Concept or an Ecosystem Idea, an Ecosystem Project is generally more fleshed out and corresponds to a relatively clear product to be built.

Summary
The AttestationStation is a central repository for attestations on OP Mainnet. One of the primary challenges currently facing the AttestationStation is the need to bootstrap the system with high-quality attestations. Luckily, blockchains already have an enormous amount of useful data that can be converted into attestations.
Some examples of existing blockchain data that can be converted into productive attestations are:

Addresses that were part of the initial ETH genesis allocation
Addresses that have held some NFT for more than X amount of time
Addresses that have donated to GitCoin rounds
Addresses that have received POAPs from important events

Converting this information into attestations makes it more accessible to developers and improves the quality of data in the AttestationStation generally. It would be valuable to have a project that can import this data into the AttestationStation in a verifiable way. Here, "verifiable" means that another user can replicate the process that was used to generate the attestations to confirm that all of the attestations were generated properly. That user can then trust that the attestations are correct and can begin to use them in their own applications.
Possible Features

Specify queries or scripts that pull blockchain data and convert that data into attestations
Allow developers to easily reproduce the queries/scripts to verify the attestations
Consider creating a system that makes it easy to do this for arbitrary queries.

Really good idea !


Add lost change to dep-prune from latest logging change

What this PR does / why we need it:
It seems like I lost a part of the PR which did the glog replacement with our own glogger. It seems that CI still continues to work, but under some situations, glide overrides the created symlink and we have no glog there at all, so we have to recreate it.
Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #
Special notes for your reviewer:
Release note:
NONE

@rmohr
I see issues still after make dep-install
➜  upstream-kubevirt git:(master) md5sum pkg/staging/glog/glog.go
6de3d30bca7b109124143307d64f317c  pkg/staging/glog/glog.go

➜  upstream-kubevirt git:(master) md5sum vendor/github.com/golang/glog/glog.go
6de3d30bca7b109124143307d64f317c  vendor/github.com/golang/glog/glog.go

There is really no changes. (i.e.: via git status)
Building from w/ this change still doesn't fix
vendor/kubevirt.io/kubevirt/pkg/log/log.go:58:24: undefined: glog.LogLevel
vendor/kubevirt.io/kubevirt/pkg/log/log.go:59:24: undefined: glog.LogLevel
Makefile:39: recipe for target 'vet' failed

However, it doesn't make sense since I see this
// This package reimplements github.com/golang/glog and logs to a structured logger.
package glog

import (
	"bytes"
	"flag"
	"fmt"
	"io"
	stdLog "log"
	"os"
	"path/filepath"
	"runtime"
	"strconv"
	"strings"
	"sync/atomic"
	"time"

	log2 "github.com/go-kit/kit/log"
)

type LogLevel int32

const (
	INFO LogLevel = iota
	WARNING
	ERROR
	FATAL
)

Note that the package manager is correct.
https://github.com/golang/glog/blob/master/glog.go
has no loglevel.
The problem is this.
Kubevirt's shadow package contains glog.LogLevel  and upstream does.
my app uses proper upstream glog.
The dependency solver will fetch the correct glog github.com/golang/glog from github.
When it sees that dependency the build system will look in the right directory - upstream.
not in the kubevirt's shadow package.
I think the real change is to create a kvirtlogger and to not shadow upstream packages.

Looking at the code, the functionality of "github.com/go-kit/kit/log" that kubevirt uses is rather minimal.
I.e.: not sure it's worth the shadow package.
If you look at the dependency of the build system, kubevirt explicitly excludes a bunch of packages from go-kit.

I think to unblock me and to leave the discussion, we should backport the DiskSecret patch to 0.9.1 -> 0.9.2 while we make the bigger change of fixing the logger
@fabiand  - thoughts?

Also, i think if you use glog.Level vs glog.LogLevel  it might work. let me give this a shot.

@rmohr  - so i tested the idea of rolling back to 0.9.0 and porting my disksecret changes and it works.
It's a hack: https://github.com/senior7515/kubevirt/releases/tag/v<IP_ADDRESS>
but will work for this. thanks.

@rmohr any further comment?

I think the real change is to create a kvirtlogger and to not shadow upstream packages.

That's what we did so far. The main issue is that we have now different sources for our logs, also that the glog logs are non-structured, whereas we are using a structured logger.
The structured logger makes it pretty easy to track objects across the clusters in logs via things like e.g.:
logger.Object(vmi).Reason(err).Error("this or that failed")

So at least from my perspective having a structured looger is worth it.
glog also directly uses os.Stderr. An alternative would probably be to replace os.Stderr with our own stream, process the glog output and then log to the original  Stderr. If we also take the glog flag dependencies into account, it might work.

Looking at the code, the functionality of "github.com/go-kit/kit/log" that kubevirt uses is rather minimal.

Yes it is rather minimal and it could  for instance as well have been logrus instead.

ill submit a PR for backporting the disk secret type to the 0.9.1 tag.  i
tested that and it seems to work. doing clustwr testing this week.
Sent from my mobile, please excuse my handwriting.
On Mon, Oct 15, 2018, 6:31 AM Roman Mohr<EMAIL_ADDRESS>wrote:

I think the real change is to create a kvirtlogger and to not shadow
upstream packages.
That's what we did so far. The main issue is that we have now different
sources for our logs, also that the glog logs are non-structured, whereas
we are using a structured logger.
The structured logger makes it pretty easy to track objects across the
clusters in logs via things like e.g.:
logger.Object(vmi).Reason(err).Error("this or that failed")
So at least from my perspective having a structured looger is worth it.
glog also directly uses os.Stderr. An alternative would probably be to
replace os.Stderr with our own stream, process the glog output and then log
to the original Stderr. If we also take the glog flag dependencies into
account, it might work.
Looking at the code, the functionality of "github.com/go-kit/kit/log"
that kubevirt uses is rather minimal.
Yes it is rather minimal and it could for instance as well have been
logrus https://github.com/sirupsen/logrus instead.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/kubevirt/kubevirt/pull/1614#issuecomment-429794794,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAKsZipqmxMSFU3khuHWoGOjxgjGw778ks5ulGPrgaJpZM4XZ4fm
.

@senior7515 I updated the PR. It should now work again with transitive build. Would be happy if you can give it a try.

@senior7515 I updated the PR. It should now work again with transitive build. Would be happy if you can give it a try.

@senior7515 needed it merged but it would still be great if you could give it a try.


Error while running the Keras example

So I was running the b_Secure_Classification_with_TFE_Keras_Secure_Model_Serving_  notebook and got the following error:
TypeError: run() got an unexpected keyword argument 'tag `
TypeError                                 Traceback (most recent call last)
<ipython-input-12-ad867501d4fb> in <module>
  9     sess,
 10     num_steps=3,
---> 11     step_fn=step_fn)

~\AppData\Local\Continuum\anaconda3\lib\site-packages\tf_encrypted\serving\queues.py in
run(self, sess, num_steps, step_fn)
 55     if num_steps is not None:
 56       for _ in range(num_steps):
---> 57         self.run_step(sess)
 58         if step_fn is not None:
 59           step_fn()

~\AppData\Local\Continuum\anaconda3\lib\site-packages\tf_encrypted\serving\queues.py in
run_step(self, sess, tag)
 45     Serve single computation.
 46     """
---> 47     sess.run(self.step_op, tag=tag)
 48
 49   def run(self, sess, num_steps=None, step_fn=None):

Any help would be really appreciated!

Hi @burhanusman, can you provide some environment information?  OS, and version numbers for all of syft, tensorflow, and tf-encrypted would be helpful to get to the bottom of this one!
Also, it looks like you may have modified the notebook, so if you can share your code that would be great as well!

Hi @jvmancuso, thanks for looking into this.
I'm using Windows 10.
Syft is not installed.
tenserflow - 1.14.0
tf-encrypted - 0.5.7
I haven't modified the notebook, I was running it as it is on Github.
So it seems like the session.run() doesn't have 'tag' as a parameter, but we are passing 'tag' while calling it.

Good catch! Sorry, thought you were referring to the PySyft notebooks in the Udacity course. This will be fixed once #639 is merged/released.  In the meantime, you can patch it yourself by changing the line
from tensorflow.keras import backend as K

from cell 1 to
from tf_encrypted.keras import backend as K


Feature Support array_compact function

Proposed changes
Issue Number: close #xxx
Problem summary
Describe your changes.
Checklist(Required)

Does it affect the original behavior:

[ ] Yes
[ ] No
[ ] I don't know

Has unit tests been added:

[ ] Yes
[ ] No
[ ] No Need

Has document been added or modified:

[ ] Yes
[ ] No
[ ] No Need

Does it need to update dependencies:

[ ] Yes
[ ] No

Are there any changes that cannot be rolled back:

[ ] Yes (If Yes, please explain WHY)
[ ] No

Further comments
If this is a relatively large or complex change, kick off the discussion at<EMAIL_ADDRESS>by explaining why you chose the solution you did and what alternatives you considered, etc...

TeamCity pipeline, clickbench performance test result:
the sum of best hot time: 33.94 seconds
load time: 452 seconds
storage size:<PHONE_NUMBER>0 Bytes
https://doris-community-test-1308700295.cos.ap-hongkong.myqcloud.com/tmp/20221110041315_clickbench_pr_43100.html

please rebase

need rebase


Fixed travis build

#447 fixed.

@nurolopher great job.
It was much more work than I thought, I will merge this on master
But we still need to fix the coverage report, do you have any ideia of how to do that?

Can you open an issue and explain the problem? Because even do not know what the problem is yet.


Use Github Actions to generate PDFs automatically

CircleCI was not working because the docker container being used no longer contains the FontAwesome package and it was failing to complete the compile process. Github Actions replaces CircleCI here and I added the font into the docker container.
This PR also makes it so that PDFs are auto-uploaded as releases after a new push instead of having PDFs in the repo itself.

That's awesome @vpatel9202 thank you, may I ask why CV_SECRETS is being used instead of GITHUB_TOKEN? https://github.com/posquit0/Awesome-CV/blob/b35674610c4b33d2cd4b45238bd3032fd3173dea/.github/workflows/main.yml#L32

Oh, seems the commit failed to close it. Thanks!


To @flow: MacroExpander.

Fixes #842.

For sanity, I moved some logic into a private method, which I prefixed by _ as I see that convention in a couple of other places. It kinda helps me to know more readily what methods are not intended to be called from outside the module. Should I put the convention in other places as well?
I re-added the caching for macros defined using strings and not functions.
In the recently-submitted updates to MacroExpander.js, I noticed that expansion.call(this) was used as opposed to just expansion(this) and taking an explicitly-defined parameter. For type safety, I'm inclined toward the latter, but it's not obvious for me why expansion.call(this) was preferred; any insights? @edemaine @kevinbarabash E.g. Currently, if I mistakenly change my code to lookup() instead of lookup.call(this), flow doesn't give a type error since the function's signature doesn't indicate any required this.

Regarding the @flow typechecker failing to catch the error in (3): https://github.com/facebook/flow/issues/4809

Regarding Point 3: This was my call: I thought it was nice to be given the MacroExpander as this in the macro function (jquery style? feels more object oriented?), but I could easily see switching to an argument style -- the latter would actually be more consistent with the rest of the code base (in particular functions.js).  So happy to go either way.  @kevinbarabash opinion?

I think we should strive for consistency where possible.  Also, many of people find this confusing calling functions directly instead of using .call will hopefully make our code easier to understand.

Thank you both for the background. I do prefer keeping code as familiar as possible. Though this is reminiscent of a familiar object-oriented style, its frequent rebinding in javascript can be confusing to newcomers to the language who don't expect to see this outside the context of a class definition. As such, I avoid taking advantage of it if there's a viable/ergonomic alternative. Per your feedback, I've switched to using an explicit parameter.
As there are numerous methods in MacroExpander, it's not immediately obvious to me which are intended to be part of its public interface.

I've defined a MacroContextInterface in macros.js to encapsulate the ones that are currently used by macro definitions. Please let me know if any more of the existing methods should be added there.

As I didn't receive any feedback regarding (1), I've prefixed the other methods that I think are intended to be private by _.

I've pushed my changes. Please correct me if any of the methods I marked private are actually intended to be public, or if the _ notation is stylistically undesirable.

(moving discussion here) I'm not a huge fan of making those methods. (Sorry for not responding to (1) earlier.) I think all of these operations could be useful in implementing sophisticated macros... But could go either way.

O wait. Gonna rebase to new master.

I'm seeing "Merging is blocked.
Merging can be performed automatically once the requested changes are addressed"
Any idea why? Do I have to mark any comments as resolved?

Any idea why? Do I have to mark any comments as resolved?

I have to click "Approve changes" after reviewing them.

We can save some space by using the loose option on transform-es2015-spread babel plugin.  I'm going to approve this, but we should fix #850 before publishing.

@marcianx thanks for PR.  I'm excited about how quickly we're updating our code to use flow.


mypy version updated 0.641

Solved Issue : #10642
I have tested it in my vagrant env. ,  it has passed all the tests except one which I found is not related with what I committed.
mypy version 0.641
and
mypy_extensions 0.4.1
typing_extensions 3.6.6 added
typing_extension is required by  mypy version 0.641

-> test at which it failed

@Adi2612 look at the test failures on the other platforms; one of them is tools/run-mypy failing.

@hackerkid might be helpful in debugging this, since it seems to have to do with stubs:
https://circleci.com/gh/zulip/zulip/13858?utm_campaign=vcs-integration-link&utm_medium=referral&utm_source=github-build-link

@timabbott  @hackerkid
With mypy == 0.620 (when nothing is changed) and with mypy ==0.641 , I am getting same error.

@timabbott I am getting same error ( https://circleci.com/gh/zulip/zulip/13858?utm_campaign=vcs-integration-link&utm_medium=referral&utm_source=github-build-link ) on my vagrant with mypy==0.641 but with mypy=0.620 I am not getting any.
I think it can be due to some method change in the latest version of mypy which is interpreting  keyword argument in different way. I have also tested with mypy==0.630 but getting the same error

Right, that's the reason we didn't just upgrade: the mypy type checker changes with each release, and catches issues that it didn't catch before.  The actual project here is to debug those errors and figure out how to fix them.

@timabbott #10703 fixes the issue behind this error.

I merged that; @Adi2612 can you rebase your work?

@timabbott  , Done . Is "codecov/project" a new  kinda test . It was not there last time.

@Adi2612 no, it's not new, but Codecov is flaky (because the vendor sucks, not because of anything we're doing).

Merged as f4d4c55d92b8a5fb88d1ae3cda37db0b32c6b60a, after cleaning up the commit message to match our style.  Thanks for the contribution @Adi2612!


API generation fails when you have a  type that has default= ""

As described
Via @founderYonz

Fixed in v2.2.5 - please verify! @yfeleke

Just verified it with 2.2.6


Indefinite wait-for-device step

I was running succesfully this plugin with my local machine. But when I use the same in my deployment server, this plugin just freezed at waiting for device step. It's not moving after this step. Please help.
Following is the logs.
Fastlane version:
$ bundle "exec" "fastlane" "--version"
fastlane installation at path:
/usr/local/lib/ruby/gems/2.5.0/gems/fastlane-2.108.0/bin/fastlane
-----------------------------
+----------------------------------+---------+------------------+
|                         Used plugins                          |
+----------------------------------+---------+------------------+
| Plugin                           | Version | Action           |
+----------------------------------+---------+------------------+
| fastlane-plugin-android_emulator | 0.1.1   | android_emulator |
+----------------------------------+---------+------------------+
[08:22:47]: Sending anonymous analytics information
[08:22:47]: Learn more at https://docs.fastlane.tools/#metrics
[08:22:47]: No personal or sensitive data is sent.
[08:22:47]: You can disable this by adding `opt_out_usage` at the top of your Fastfile
[08:22:47]: ----------------------------------------
[08:22:47]: --- Step: Verifying fastlane version ---
[08:22:47]: ----------------------------------------
[08:22:47]: Your fastlane version 2.108.0 matches the minimum requirement of 2.99.0  ✅
[08:22:47]: ------------------------------
[08:22:47]: --- Step: default_platform ---
[08:22:47]: ------------------------------
[08:22:47]: Driving the lane 'android screenshots' 🚀
[08:22:47]:
Fastfile:792: warning: already initialized constant Fastlane::FastFile::ChainNames
Fastfile:791: warning: previous definition of ChainNames was here
[08:22:47]:
[08:22:47]:
[08:22:47]:
[08:22:47]: --------------------------------------------------------
[08:22:47]: --------------------------------------------------------
[08:22:47]: Starting Android Virtual Device now
[08:22:47]: --------------------------------------------------------
[08:22:47]: --------------------------------------------------------
[08:22:47]: ------------------------------
[08:22:47]: --- Step: android_emulator ---
[08:22:47]: ------------------------------
[08:22:47]: Stopping emulator
[08:22:49]: Creating new emulator
[08:22:57]: ▸ Auto-selecting single ABI x86
[08:23:26]: Override configuration
[08:23:26]: Starting emulator
[08:23:26]: $ $ANDROID_HOME/platform-tools/adb -e wait-for-device

Hi @samsonpaul87,
We did experience the same problem on one of our machines:
ci$ /usr/local/Caskroom/android-sdk/3859397,26.0.2/tools/emulator @fastlane qemu-system-x86_64: -drive if=none,index=0,id=system,file=/usr/local/Caskroom/android-sdk/3859397,26.0.2/system-images/android-24/google_apis/x86_64//system.img,read-only: Could not open '/usr/local/Caskroom/android-sdk/3859397': No such file or directory
The problem is the directory contains a comma.
We just removed the sdk folder and reinstalled it with:
brew cask install android-sdk android-platform-tools
Let me know if you need further help