What is the naming convention needed for deploys to be picked up?

[David Inkpen]

I've got the integration with GitHub working for a component. 

A workflow named "Deploy UAT" runs, and is successfully shown in the Activity view.

However, it appears under "Other" instead of "Deployments".

I've also tried explicitly setting the `environment: uat` within the workflow to no avail.

What is the naming convention needed to pick up the deployment?

[faraz rashdi]

The naming convention needed for deploys to be picked up can vary depending on the deployment tool or system you are using. However, there are some common naming conventions that are often used to ensure deploys are picked up correctly:

1. **Semantic Versioning**: Using semantic versioning for your deploy names can help organize and track different versions of your application. Semantic versioning typically follows the format `major.minor.patch`, where each part represents a different level of change in the software. For example, `v1.2.3` indicates major version 1, minor version 2, and patch version 3.

2. **Timestamps**: Including timestamps in deploy names can provide a clear indication of when each deploy occurred. Timestamps are often formatted in a way that is sortable and easily readable, such as `YYYYMMDDHHMMSS` (year, month, day, hour, minute, second).

3. **Environment Indicator**: Adding an environment indicator to deploy names can help distinguish between different environments, such as development, staging, and production. For example, you might use prefixes like `dev-`, `stage-`, or `prod-` to indicate the environment.

4. **Branch Name**: Including the name of the branch being deployed can be useful for tracking changes and debugging issues related to specific branches. This is especially relevant in continuous integration/continuous deployment (CI/CD) workflows.

5. **Release Name or Tag**: If your deployment process involves creating releases or tags in your version control system (e.g., Git), you can use the release or tag name as part of the deploy name. This helps link the deploy to a specific release or version of your application.

6. **Descriptive Labels**: Including descriptive labels or identifiers in deploy names can provide additional context about the changes included in the deploy. This might include features, bug fixes, or other relevant information.

Here's an example of a deploy name incorporating some of these elements:

```
v1.2.3-prod-20220501-143000
```

This deploy name indicates that it is version 1.2.3 deployed to the production environment on May 1, 2022, at 2:30:00 PM.

It's important to establish a consistent naming convention that works well for your team and aligns with your deployment process and tooling. Additionally, ensure that your deployment tool or system is configured to recognize and process deploy names according to your chosen convention.

[Steffen Opel _Utoolity_]

The GitHub environment name mapping documents the applied naming convention for the environment type, and it maps 'uat' to 'testing', i.e. it seems supported as such (the keywords are case insensitive):

The GitHub app for Compass evaluates the name of your GitHub Environment for all deployment events and uses a mapping to determine what environment type (Production, Staging, etc.) it falls into. We look for the presence of the below words within the name of the environment to determine the type.

• production: "production", "prod", "prd", "live"
• staging: "staging", "stage", "stg", "preprod", "model", "internal"
• testing: "testing", "test", "tests", "tst", "integration", "integ", "intg", "int", "acceptance", "accept", "acpt", "qa", "qc", "control", "quality", "uat", "sit", "canary"
• development: "development", "dev", "trunk"

In the case that an environment name matches more than one type, we use the order shown above to determine the mapping. For example, if your environment is named "dev-prod" we would map it to Production.

That being said, what you describe seems to indicate that your workflow isn't even recognized as a deployment in the first place - can you verify that the optional keyword deployment is present in your workflow? For example:

jobs:
  deployment:
    runs-on: ubuntu-latest
    environment: uat
    steps:
      - name: deploy
        # ...deployment-specific steps