Update CONTRIBUTING.md with new docs link

The docs for k6chaijs have moved to the grafana docs.

CONTRIBUTING.md

@@ -1,4 +1,4 @@
-# Contributing
+/docs.# Contributing
 
 ## Adding a new service
 
@@ -10,7 +10,7 @@ If the jslib-aws does not support the service you need yet, the best way to get
 2. The project files should be formatted using the [Prettier](https://prettier.io/) tool. The project has a `.prettierrc.json` file containing the tool's configuration.
 3. The project uses webpack to produce build files. Because k6 does not have native support typescript, and its Javascript runtime does not support the `import` statement, the project uses webpack to produce a file containing all the code that k6 scripts can use. The project has a `webpack.config.js` file containing the tool's configuration. Each service is built into its dedicated file, and an overarching `aws.js` contains them for convenience.
 4. To allow easier testing, files in the `src` directory are organized in a public/private structure. Files at the root of the folder are the public files; they import the content of the internal (private) directory and explicitly export the symbols that should be made available to the user. The internal files are the ones that contain the actual implementation of the service. The internal files are not exported and are not meant to be used directly by the user.
-5. The project is tested in an end2end fashion using the [k6](https://k6.io/) tool. The tests live in the `tests` directory. The tests are written in Javascript and use the [k6 chai js](https://k6.io/docs/javascript-api/jslib/k6chaijs/) jslib to test the functionality of the library. The `npm test` command runs the test suites. The tests run in a docker container, and the `docker-compose.yml` file contains the configuration for the container. The docker-compose setup spins up a [localstack](https://https://github.com/localstack/localstack) setup, which emulates AWS locally, and the test script performs its assertions against it directly.
+5. The project is tested in an end2end fashion using the [k6](https://k6.io/) tool. The tests live in the `tests` directory. The tests are written in Javascript and use the [k6 chai js](https://grafana.com/docs/k6/latest/javascript-api/jslib/k6chaijs) jslib to test the functionality of the library. The `npm test` command runs the test suites. The tests run in a docker container, and the `docker-compose.yml` file contains the configuration for the container. The docker-compose setup spins up a [localstack](https://https://github.com/localstack/localstack) setup, which emulates AWS locally, and the test script performs its assertions against it directly.
 
 ### Conventions
 
@@ -26,7 +26,7 @@ If the jslib-aws does not support the service you need yet, the best way to get
 4. Most service operations require signing requests using the AWS V4 signature process. The `SignatureV4` construct exposed in the [`src/internal/signature.ts`](https://github.com/grafana/k6-jslib-aws/blob/main/src/internal/signature.ts#L9) file allows signing requests to AWS services easily. Checkout the existing service implementations for examples of how to use it: [in S3Client](https://github.com/grafana/k6-jslib-aws/blob/main/src/internal/s3.ts#L48), and [in SecretsManagerService](https://github.com/grafana/k6-jslib-aws/blob/main/src/internal/secrets-manager.ts#L63) for instance.
 5. Add a new [entry](https://webpack.js.org/concepts/entry-points/) in `webpack.config.js` to the service you created in Step 1.
 6. Tests verifying that the service class works as expected should be added in the `tests/internal` directory. The dedicated test file should follow the same naming convention as the service class file, except it should have the `.js` extension. For example, if the service class file is named `systems-manager.ts`, the test file should be called `systems-manager.js`.
-7. Test files should consists in a k6 script using the [k6 chai js](https://k6.io/docs/javascript-api/jslib/k6chaijs/) library, and exporting a single `{serviceName}TestSuite(data)` function. This function should consist of a set of `describe` statements containing the actual test assertions, as demonstrated in the [existing s3 test suite](https://github.com/grafana/k6-jslib-aws/blob/main/tests/internal/s3.js). The test suite should be imported and called in the [`tests/internal/index.js`](https://github.com/grafana/k6-jslib-aws/blob/main/tests/index.js) test script, which is the entry point for the test suite.
+7. Test files should consists in a k6 script using the [k6 chai js](https://grafana.com/docs/k6/latest/javascript-api/jslib/k6chaijs) library, and exporting a single `{serviceName}TestSuite(data)` function. This function should consist of a set of `describe` statements containing the actual test assertions, as demonstrated in the [existing s3 test suite](https://github.com/grafana/k6-jslib-aws/blob/main/tests/internal/s3.js). The test suite should be imported and called in the [`tests/internal/index.js`](https://github.com/grafana/k6-jslib-aws/blob/main/tests/index.js) test script, which is the entry point for the test suite.
 8. If the tests depend on a specific pre-existing state of the localstack setup, you can add a dedicated script in the `tests/internal/localstack_init` folder. Localstack will execute all the commands present in this script during its setup phase.
 9. The `npm test` command runs the test suite. This command will build the project and run the tests against the spun-up localstack docker container. The `docker-compose.yml` file contains the configuration for the container.
 10. Once the tests pass, the `src/index.ts` file should export the service class in the `src/index.ts` file so the user can use it.