Compare commits

...

3 Commits

Author SHA1 Message Date
Data Scientist | AI Engineer | Principal Software Engineer
41182c0616
Merge d9b07c3588 into 65d868f8d4 2025-12-18 22:38:13 +00:00
mahabaleshwars
65d868f8d4
Update Documentation for Lockfile (#1454)
* update documentation for lockfile

* Update adavance usage in README.md

* Documentation update

* Update lockfile documenation

* fix coplilot suggestion
2025-12-18 10:49:55 -06:00
Data Scientist | AI Engineer | Principal Software Engineer
d9b07c3588
Add GitHub Actions workflow for GKE deployment
This workflow builds a Docker container, publishes it to Google Container Registry, and deploys it to GKE on pushes to the main branch. It includes steps for authentication, Docker image building, and deployment configuration.
2025-11-03 10:18:50 +05:30
3 changed files with 138 additions and 2 deletions

116
.github/workflows/google.yml vendored Normal file
View File

@ -0,0 +1,116 @@
# This workflow will build a docker container, publish it to Google Container
# Registry, and deploy it to GKE when there is a push to the "main"
# branch.
#
# To configure this workflow:
#
# 1. Enable the following Google Cloud APIs:
#
# - Artifact Registry (artifactregistry.googleapis.com)
# - Google Kubernetes Engine (container.googleapis.com)
# - IAM Credentials API (iamcredentials.googleapis.com)
#
# You can learn more about enabling APIs at
# https://support.google.com/googleapi/answer/6158841.
#
# 2. Ensure that your repository contains the necessary configuration for your
# Google Kubernetes Engine cluster, including deployment.yml,
# kustomization.yml, service.yml, etc.
#
# 3. Create and configure a Workload Identity Provider for GitHub:
# https://github.com/google-github-actions/auth#preferred-direct-workload-identity-federation.
#
# Depending on how you authenticate, you will need to grant an IAM principal
# permissions on Google Cloud:
#
# - Artifact Registry Administrator (roles/artifactregistry.admin)
# - Kubernetes Engine Developer (roles/container.developer)
#
# You can learn more about setting IAM permissions at
# https://cloud.google.com/iam/docs/manage-access-other-resources
#
# 5. Change the values in the "env" block to match your values.
name: 'Build and Deploy to GKE'
on:
push:
branches:
- '"main"'
env:
PROJECT_ID: 'my-project' # TODO: update to your Google Cloud project ID
GAR_LOCATION: 'us-central1' # TODO: update to your region
GKE_CLUSTER: 'cluster-1' # TODO: update to your cluster name
GKE_ZONE: 'us-central1-c' # TODO: update to your cluster zone
DEPLOYMENT_NAME: 'gke-test' # TODO: update to your deployment name
REPOSITORY: 'samples' # TODO: update to your Artifact Registry docker repository name
IMAGE: 'static-site'
WORKLOAD_IDENTITY_PROVIDER: 'projects/123456789/locations/global/workloadIdentityPools/my-pool/providers/my-provider' # TODO: update to your workload identity provider
jobs:
setup-build-publish-deploy:
name: 'Setup, Build, Publish, and Deploy'
runs-on: 'ubuntu-latest'
environment: 'production'
permissions:
contents: 'read'
id-token: 'write'
steps:
- name: 'Checkout'
uses: 'actions/checkout@692973e3d937129bcbf40652eb9f2f61becf3332' # actions/checkout@v4
# Configure Workload Identity Federation and generate an access token.
#
# See https://github.com/google-github-actions/auth for more options,
# including authenticating via a JSON credentials file.
- id: 'auth'
name: 'Authenticate to Google Cloud'
uses: 'google-github-actions/auth@f112390a2df9932162083945e46d439060d66ec2' # google-github-actions/auth@v2
with:
workload_identity_provider: '${{ env.WORKLOAD_IDENTITY_PROVIDER }}'
# Authenticate Docker to Google Cloud Artifact Registry
- name: 'Docker Auth'
uses: 'docker/login-action@9780b0c442fbb1117ed29e0efdff1e18412f7567' # docker/login-action@v3
with:
username: 'oauth2accesstoken'
password: '${{ steps.auth.outputs.auth_token }}'
registry: '${{ env.GAR_LOCATION }}-docker.pkg.dev'
# Get the GKE credentials so we can deploy to the cluster
- name: 'Set up GKE credentials'
uses: 'google-github-actions/get-gke-credentials@6051de21ad50fbb1767bc93c11357a49082ad116' # google-github-actions/get-gke-credentials@v2
with:
cluster_name: '${{ env.GKE_CLUSTER }}'
location: '${{ env.GKE_ZONE }}'
# Build the Docker image
- name: 'Build and push Docker container'
run: |-
DOCKER_TAG="${GAR_LOCATION}-docker.pkg.dev/${PROJECT_ID}/${REPOSITORY}/${IMAGE}:${GITHUB_SHA}"
docker build \
--tag "${DOCKER_TAG}" \
--build-arg GITHUB_SHA="${GITHUB_SHA}" \
--build-arg GITHUB_REF="${GITHUB_REF}" \
.
docker push "${DOCKER_TAG}"
# Set up kustomize
- name: 'Set up Kustomize'
run: |-
curl -sfLo kustomize https://github.com/kubernetes-sigs/kustomize/releases/download/kustomize%2Fv5.4.3/kustomize_v5.4.3_linux_amd64.tar.gz
chmod u+x ./kustomize
# Deploy the Docker image to the GKE cluster
- name: 'Deploy to GKE'
run: |-
# replacing the image name in the k8s template
./kustomize edit set image LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY/IMAGE:TAG=$GAR_LOCATION-docker.pkg.dev/$PROJECT_ID/$REPOSITORY/$IMAGE:$GITHUB_SHA
./kustomize build . | kubectl apply -f -
kubectl rollout status deployment/$DEPLOYMENT_NAME
kubectl get services -o wide

View File

@ -148,7 +148,7 @@ Since it will not be cached always, there is possibility of hitting rate limit w
### Checking in lockfiles ### Checking in lockfiles
It's **always** recommended to commit the lockfile of your package manager for security and performance reasons. For more information consult the "Working with lockfiles" section of the [Advanced usage](docs/advanced-usage.md#working-with-lockfiles) guide. It's **strongly recommended** to commit the lockfile of your package manager for security and performance reasons. For more information consult the "Working with lockfiles" section of the [Advanced usage](docs/advanced-usage.md#working-with-lockfiles) guide.
## Caching global packages data ## Caching global packages data
@ -249,6 +249,7 @@ If the runner is not able to access github.com, any Nodejs versions requested du
- [Publishing to npmjs and GPR with npm](docs/advanced-usage.md#publish-to-npmjs-and-gpr-with-npm) - [Publishing to npmjs and GPR with npm](docs/advanced-usage.md#publish-to-npmjs-and-gpr-with-npm)
- [Publishing to npmjs and GPR with yarn](docs/advanced-usage.md#publish-to-npmjs-and-gpr-with-yarn) - [Publishing to npmjs and GPR with yarn](docs/advanced-usage.md#publish-to-npmjs-and-gpr-with-yarn)
- [Using private packages](docs/advanced-usage.md#use-private-packages) - [Using private packages](docs/advanced-usage.md#use-private-packages)
- [Using private mirror](docs/advanced-usage.md#use-private-mirror)
## Recommended permissions ## Recommended permissions

View File

@ -1,6 +1,6 @@
## Working with lockfiles ## Working with lockfiles
All supported package managers recommend that you **always** commit the lockfile, although implementations vary doing so generally provides the following benefits: Most supported package managers recommend that you **always** commit the lockfile, although implementations vary doing so generally provides the following benefits:
- Enables faster installation for CI and production environments, due to being able to skip package resolution. - Enables faster installation for CI and production environments, due to being able to skip package resolution.
- Describes a single representation of a dependency tree such that teammates, deployments, and continuous integration are guaranteed to install exactly the same dependencies. - Describes a single representation of a dependency tree such that teammates, deployments, and continuous integration are guaranteed to install exactly the same dependencies.
@ -35,6 +35,25 @@ Ensure that `pnpm-lock.yaml` is always committed, when on CI pass `--frozen-lock
- [Working with Git - Lockfiles](https://pnpm.io/git#lockfiles) - [Working with Git - Lockfiles](https://pnpm.io/git#lockfiles)
- [Documentation of `--frozen-lockfile` option](https://pnpm.io/cli/install#--frozen-lockfile) - [Documentation of `--frozen-lockfile` option](https://pnpm.io/cli/install#--frozen-lockfile)
### Running without a lockfile
If you choose not to use a lockfile, you must ensure that **caching is disabled**. The `cache` feature relies on the lockfile to generate a unique key for the cache entry.
To run without a lockfile:
1. Do not set the `cache` input.
2. If your `package.json` contains a `packageManager` field set to npm (or devEngines.packageManager), automatic caching is enabled by default. Override this by setting `package-manager-cache: false`.
```yaml
steps:
- uses: actions/checkout@v6
- uses: actions/setup-node@v6
with:
node-version: '24'
package-manager-cache: false # Explicitly disable caching if you don't have a lockfile
- run: npm install
- run: npm test
```
## Check latest version ## Check latest version
The `check-latest` flag defaults to `false`. When set to `false`, the action will first check the local cache for a semver match. If unable to find a specific version in the cache, the action will attempt to download a version of Node.js. It will pull LTS versions from [node-versions releases](https://github.com/actions/node-versions/releases) and on miss or failure will fall back to the previous behavior of downloading directly from [node dist](https://nodejs.org/dist/). Use the default or set `check-latest` to `false` if you prefer stability and if you want to ensure a specific version of Node.js is always used. The `check-latest` flag defaults to `false`. When set to `false`, the action will first check the local cache for a semver match. If unable to find a specific version in the cache, the action will attempt to download a version of Node.js. It will pull LTS versions from [node-versions releases](https://github.com/actions/node-versions/releases) and on miss or failure will fall back to the previous behavior of downloading directly from [node dist](https://nodejs.org/dist/). Use the default or set `check-latest` to `false` if you prefer stability and if you want to ensure a specific version of Node.js is always used.