actions
actions copied to clipboard
build performance
The Build netlify/actions/cli@master
step takes ~1min which decreases the CD performance a lot.
Is there a way to optimize the performance? Could a tagged release help if GitHub caches the result?
yes, same issue
I looked into this a while back: https://steele.blue/tiny-github-actions/
From what I'd found, the only way to prevent rebuilding the Docker container each time is to publish the built container to Docker Hub, and pull the entire container, a la uses: docker://netlify/cli-action:latest
or something.
This can save build time, but it can also increase the download time, depending on the size of the Docker container it has to download. Given that its base is node10:alpine
it probably would be OK, but not a guarantee.
Another nit: if you're pulling prebuilt containers, it'd be nice to pull from the GitHub Package Registry instead of Docker Hub, but this isn't supported yet: https://github.community/t5/GitHub-Actions/How-to-use-GitHub-registry-docker-image-in-a-service/m-p/33965#M1733
I see @kitop committed the original Dockerfile https://github.com/netlify/actions/commits/master/build/Dockerfile
I wonder if he'd be up for publishing the docker image, rather than every GitHub build using it needing to build it every time.
I takes my Hugo site one second to build and four seconds to publish to Netlify. The Netlify action build take 70 seconds.
For the moment I have much better performance by running yarn global add netlify
myself in a simple step.
@Gummibeer - I just tried that:
- name: Install netlify-cli
run: yarn global add netlify
And got:
"[email protected]" has no binaries
Actually I changed it to netlify-cli
and install worked:
yarn global add netlify-cli
yarn global v1.22.4
[1/4] Resolving packages...
warning netlify-cli > copy-template-dir > readdirp > micromatch > snapdragon > source-map-resolve > [email protected]: https://github.com/lydell/resolve-url#deprecated
warning netlify-cli > copy-template-dir > readdirp > micromatch > snapdragon > source-map-resolve > [email protected]: Please see https://github.com/lydell/urix#deprecated
[2/4] Fetching packages...
info [email protected]: The platform "linux" is incompatible with this module.
info "[email protected]" is an optional dependency and failed compatibility check. Excluding it from installation.
[3/4] Linking dependencies...
[4/4] Building fresh packages...
success Installed "[email protected]" with binaries:
- ntl
- netlify
Done in 19.30s.
However, the netlify
command is still not found in subsequent steps.
EDIT - the full correct command is:
sudo yarn global add netlify-cli
Sorry, have written from mobile - you are right that it's netlify-cli
.
That's my whole netlify deploy step:
- name: Netlify deploy
run: |
yarn global add netlify-cli
"$(yarn global bin)/netlify" deploy --prod
env:
NETLIFY_AUTH_TOKEN: ${{ secrets.NETLIFY_AUTH_TOKEN }}
NETLIFY_SITE_ID: ${{ secrets.NETLIFY_SITE_ID }}
I'm calling the command not with binary path prefix because github actions do not add this path to $PATH
. That's why I use $(yarn global bin)/netlify
instead of simple netlify
command.
Installing with sudo
seems to put it somewhere on the path, which seems a little easier to me (and should be fine in the context of a throw away CI instance).
Thanks - this reduces the time to get netlify working to 24 seconds, down nearly two thirds.
I saw this recently in the GitHub changelog. Unless I'm missing something, it looks like it would now be possible to pull a prebuilt Docker image from GitHub Package Registry?
Changelog Link: https://github.blog/changelog/2020-09-24-github-actions-private-registry-support-for-job-and-service-containers/
If any of you are still running into this problem, here's a solution that worked for us:
We built our own action that uses the GitHub Container Registry, so that we can pull a prebuilt Docker image as @mike183 suggested.
It takes about 15-25 seconds to pull the image, which is much faster than the 1-3 minutes it took to build the Netlify action.
The reason we went with Docker instead of installing netlify-cli
globally was since we wanted to keep our secrets isolated from the rest of the workflow.
A couple other advantages of building our own action:
- Non-zero exit codes fail the build, as expected
- We were able to disable the netlify-cli telemetry