Skip to content

Commit

Permalink
Update README.md
Browse files Browse the repository at this point in the history
Signed-off-by: Carlos Rodríguez Hernández <[email protected]>
  • Loading branch information
carrodher authored Mar 15, 2024
1 parent 927a470 commit 3023450
Showing 1 changed file with 9 additions and 9 deletions.
18 changes: 9 additions & 9 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -8,17 +8,17 @@ The repository contains two types of workflows:

## Reusable workflows

These workflows are, and must be, under `.github/workflows` folder due to GitHub restrictions. These files were extracted from other repositories and they were created for especific events, for that reason we tried to follow this convention `<webhook>-<activity-type>` ([About events that trigger workflows](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#about-events-that-trigger-workflows)) to name them. The main goal of these workflows is manage the [Bitnami Project support board](https://github.com/orgs/bitnami/projects/4)
These workflows are and must be, under the `.github/workflows` folder due to GitHub restrictions. These files were extracted from other repositories and they were created for specific events, for that reason we tried to follow this convention `<webhook>-<activity-type>` ([About events that trigger workflows](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#about-events-that-trigger-workflows)) to name them. The main goal of these workflows is to manage the [Bitnami Project support board](https://github.com/orgs/bitnami/projects/4)

* [`comment-created.yml`](.github/workflows/comment-created.yml): Moves cards based on issue/pr comments. Also it adds the label `review-required` if the comment was added on automated PR by bitnami-bot.
* [`comment-created.yml`](.github/workflows/comment-created.yml): Moves cards based on issue/pr comments. Also, it adds the label `review-required` if the comment was added on automated PR by bitnami-bot.
* [`item-closed.yml`](.github/workflows/item-closed.yml): Sends cards to the Solved column and adds the `solved` label.
* [`item-labeled.yml`](.github/workflows/item-labeled.yml): Moves cards according to its labels. Also it reassigns tasks if it is needed, for instance, when we are labeling with `in-progress`.
* [`item-opened.yml`](.github/workflows/item-opened.yml): Creates the item card, puts it into the Triage column and assigns it to a Bitnami Team member.
* [`item-labeled.yml`](.github/workflows/item-labeled.yml): Moves cards according to its labels. Also, it reassigns tasks if it is needed, for instance, when we are labeling with `in-progress`.
* [`item-opened.yml`](.github/workflows/item-opened.yml): Creates the item card, puts it into the Triage column, and assigns it to a Bitnami Team member.
* [`pr-review-requested-sync.yml`](.github/workflows/pr-review-requested-sync.yml): Moves the cards when a review is requested.

The [`.env` file](.env) plays an important role here. It has the following information used by previous workflows:
* BITNAMI_TEAM. Members of Bitnami Team. [Daily synced](.github/workflows/sync-teams.yml) with the [GitHub Bitnami Support Team](https://github.com/orgs/bitnami/teams/support)
* LABEL_MAPPING. All labels used by the workflows, the column associated and label to be removed when the label is set. The content of this variable is an array with that information for each label in json format, for example:
* LABEL_MAPPING. All labels used by the workflows, the column associated, and the label to be removed when the label is set. The content of this variable is an array with that information for each label in JSON format, for example:
```json
"triage": {
"column": "Triage",
Expand All @@ -31,7 +31,7 @@ The [`.env` file](.env) plays an important role here. It has the following infor
]
}
```
* REPO_ASSIGNMENT. Each repository managed by these workflows could have its own assignment, for instance, charts and containers have their own teams to manage the support tasks. It contains triage and support assignments for each repository and a default one if the repository doesn't have any specific assignee.
* REPO_ASSIGNMENT. Each repository managed by these workflows could have its assignment, for instance, charts and containers have their teams to manage the support tasks. It contains triage and support assignments for each repository and a default one if the repository doesn't have any specific assignee.
```json
{
"charts": {
Expand All @@ -55,11 +55,11 @@ The [`.env` file](.env) plays an important role here. It has the following infor

## Synced workflows

These workflows are located in `/workflows` and they are synced with the repositories configured in the [sync.yml](.github/sync.yml) file. Any change on this files will create a PR in those repositories. The main purpose of these files is to link the repository events with the reusable workflows described above.
These workflows are located in `/workflows` and they are synced with the repositories configured in the [sync.yml](.github/sync.yml) file. Any change on these files will create a PR in those repositories. The main purpose of these files is to link the repository events with the reusable workflows described above.

## Migration workflow

This workflow copies existing cards from a repository Project (Classic) board into the new organization Project (ProjectV2) board, in our case we will use the [Bitnami Support board](https://github.com/orgs/bitnami/projects/4/views/1). To use it we only need to create workflow like this one in our repository:
This workflow copies existing cards from a repository Project (Classic) board into the new organization Project (ProjectV2) board, in our case, we will use the [Bitnami Support board](https://github.com/orgs/bitnami/projects/4/views/1). To use it we only need to create a workflow like this one in our repository:

```yaml
# Copyright VMware, Inc.
Expand Down Expand Up @@ -93,4 +93,4 @@ The hard work is done by this [piece of code](.github/scripts/migrate.sh) but in
NOTES:
* The process will migrate all cards in one execution.
* If you face any error you can trigger the workflow again, no duplications should occur in the target Project.
* If you have a significant number of cards you could reach GitHub thresholds, in that case you should remove/archive previously migrated cards in the source Project (classic) to reduce the number of requests.
* If you have a significant number of cards you could reach GitHub thresholds, in that case, you should remove/archive previously migrated cards in the source Project (classic) to reduce the number of requests.

0 comments on commit 3023450

Please sign in to comment.