Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://nx.dev/reference/core-api/s3-cache/overview below:

Website Navigation

• Blog
• AI
• Nx Cloud
• Enterprise
• Get started
• Nx
• CI
• Extending Nx
• Plugins
• Changelog
• AI Chat
• Community channel
• Latest news
• Latest news on Bluesky
• Youtube channel
• Nx on LinkedIn
• Nx is open source, check the code on GitHub

Overview of the Nx S3 Cache Plugin

The @nx/s3-cache plugin enables you to self-host your remote cache on an Amazon S3 bucket.

Bucket-based caches are vulnerable to poisoning and often prohibited in organizations

Nx Cloud: Managed Multi-Tier Remote Cache [Secure]

Run the following command:

This will add the @nx/s3-cache NPM package and automatically configure it for your workspace. As part of this process you'll be guided to generate a new activation key. This is a fully automated process to register your plugin.

The key will be saved in your repository (.nx/key/key.ini) and should be committed so that every developer has access to it. If your repository is public (or in CI) you can also use an environment variable:

.env

NX_KEY=YOUR_ACTIVATION_KEY

If you didn't get an activation key or skipped that step, you can easily generate one at any time by running nx register in your terminal.

Why require an activation key? It simply helps us know and support our users. If you prefer not to provide this information, you can also build your own cache server. Learn more.

There are four different ways to authenticate with AWS. They will be attempted in this order:

1. Environment variables
2. INI config files
3. Single sign-on
4. nx.json settings

AWS provides environment variables that can be used to authenticate:

Both the AWS_ACCESS_KEY_ID and the AWS_SECRET_ACCESS_KEY environment variables are required to use the environment variable authentication method.

Here's an example of using OIDC in GitHub Actions to set the environment variables in CI:

.github/workflows/ci.yml

name: CI ... permissions: id-token: write ... jobs: main: env: NX_KEY: ${{ secrets.NX_KEY }} runs-on: ubuntu-latest steps: ... - name: 'Configure AWS Credentials' uses: aws-actions/configure-aws-credentials@v4.0.2 with: role-to-assume: arn:aws:iam::123456789123:role/GhAIBucketUserRole aws-region: us-east-1 ... - run: pnpm exec nx affected -t lint test build

AWS can read your authentication credentials from shared INI config files. The files are located at ~/.aws/credentials and ~/.aws/config. Both files are expected to be INI formatted with section names corresponding to profiles. Sections in the credentials file are treated as profile names, whereas profile sections in the config file must have the format of [profile profile-name], except for the default profile. Profiles that appear in both files will not be merged, and the version that appears in the credentials file will be given precedence over the profile found in the config file.

Nx can read the active access token created after running aws sso login then request temporary AWS credentials. You can create the AwsCredentialIdentityProvider functions using the inline SSO parameters (ssoStartUrl, ssoAccountId, ssoRegion, ssoRoleName) or load them from AWS SDKs and Tools shared configuration and credentials files. Profiles in the credentials file are given precedence over profiles in the config file.

Storing your credentials in the nx.json file is the least secure of the 4 authentication options, since anyone with read access to your codebase will have access to your AWS credentials.

nx.json

{ "s3": { "ssoProfile": "default", "accessKeyId": "MYACCESSKEYID", "secretAccessKey": "MYSECRETACCESSKEY" } }

Regardless of how you manage your AWS authentication, you need to configure your Nx cache in the nx.json file. The bucket that you specify needs to already exist - Nx doesn't create it for you.

nx.json

{ "s3": { "region": "us-east-1", "bucket": "my-bucket", "encryptionKey": "create-your-own-key" } }

To use @nx/s3-cache with S3 compatible providers (MinIO, LocalStack, DigitalOcean Spaces, Cloudflare, etc.), endpoint will need to be provided. Some providers also need to have forcePathStyle set to true in the configuration.

Below is an example on how to connect to MinIO:

nx.json

{ "s3": { "region": "us-east-1", "bucket": "my-bucket", "endpoint": "https://play.min.io", "forcePathStyle": true, "accessKeyId": "abc1234", "secretAccessKey": "4321cba", "disableChecksum": true } }

Minio and checksum validation

By default, Nx will try to write and read from the remote cache while running locally. This means that permissions must be set for users who are expected to access the remote cache.

Nx will only show warnings when the remote cache is not writable. You can disable these warnings by setting localMode to read-only or no-cache in the nx.json file.

nx.json

{ "s3": { "region": "us-east-1", "bucket": "my-bucket", "localMode": "read-only" } }

The cache mode in CI can also be configured by setting ciMode to read-only or no-cache in the nx.json file. Or by setting NX_POWERPACK_CACHE_MODE to read-only or no-cache in the CI environment.

nx.json

{ "s3": { "region": "us-east-1", "bucket": "my-bucket", "ciMode": "read-only" } }

Many people who are interested in Nx Powerpack have previously used custom task runners. Nx offers a new and simpler extension API designed to meet the same use cases as the now-deprecated custom task runners.

To learn more about migrating from custom task runners, please refer to this detailed guide.

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4