Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
10 changes: 3 additions & 7 deletions docs/deep-dive-into-hyperexecute-yaml.md
Original file line number Diff line number Diff line change
Expand Up @@ -952,14 +952,10 @@ alwaysRunPostSteps: true

This flag is used to set the Name of your Projects which would later allow you to see all jobs of that Project at one place. To know more about Projects [click here](/support/docs/hyperexecute-projects).

```yaml
project:
name: 'demo-project' #project name
```

:::info note
Once you have created a project, you can either pass in your `project ID` or `project name` to trigger your job on the same project.

- Once you have created a project, you can pass in your project ID and project name to trigger your job on the same project.
- If you are using [**Project Level Secrets**](/support/docs/hyperexecute-how-to-manage-project-level-secrets/), you must include the id field in your project configuration.
:::
```yaml
project:
name: 'demo-project' #project name
Expand Down
6 changes: 4 additions & 2 deletions docs/hyperexecute-how-to-manage-project-level-secrets.md
Original file line number Diff line number Diff line change
Expand Up @@ -45,7 +45,7 @@ Secrets in <BrandName /> HyperExecute are encrypted environment variables used t
Managing sensitive information like API tokens, credentials, and access keys is crucial when running tests in <BrandName /> HyperExecute. To address this, HyperExecute offers a Secrets Management system, and one of its powerful features is Project Level Secrets. This feature lets you define secrets scoped to a specific project, making secret handling more secure, easier, and collaborative for your teams.

## What Are Project Level Secrets?
Project-level secrets are bound to a specific HyperExecute project instead of a user or account. When a job runs using that project (referenced by name or id in the YAML configuration, which is a sub-parameter of project parameter), the project-level secrets are automatically available to the test environment.
Project-level secrets are bound to a specific HyperExecute project instead of a user or account. When a job runs using that project ( referenced by id or both id and name in the YAML configuration, which is a sub-parameters of project parameter), the project-level secrets are automatically available to the test environment.

### Key Points
- Define secrets once per project.
Expand Down Expand Up @@ -76,7 +76,9 @@ runson: linux
autosplit: true
concurrency: 2

project: your-project-name
project:
name: 'demo-project'
id: '1abc2345-56de-7890-f1cg-h2ij34k56789'

# highlight-start
env:
Expand Down
4 changes: 3 additions & 1 deletion docs/support-access.md
Original file line number Diff line number Diff line change
Expand Up @@ -46,7 +46,9 @@ import BrandName, { BRAND_URL } from '@site/src/component/BrandName';
***
The Support Access feature allows <BrandName /> to take access to your <BrandName /> account and log in on your behalf from the backend. By granting access to your account, our team can help you with debugging issues or do activities on your behalf. You can revoke this access anytime


:::tip Quick Link
You can directly navigate to the Support Access page by this [**link**](https://accounts.lambdatest.com/support).
:::
## Granting Support Access
***

Expand Down
Loading