Skip to content

Commit edcfc03

Browse files
Update readme (#14)
1 parent c28fc86 commit edcfc03

1 file changed

Lines changed: 171 additions & 39 deletions

File tree

README.md

Lines changed: 171 additions & 39 deletions
Original file line numberDiff line numberDiff line change
@@ -27,42 +27,174 @@ The following tools assume that you use the structure detailed by this repositor
2727
config.json
2828
```
2929

30-
## GitHub Actions
31-
32-
- [Run Liquid Tests](https://github.com/silverfin/example_liquid_repository/blob/main/.github/run_tests.yml)
33-
- [Update Liquid Templates - Review](https://github.com/silverfin/example_liquid_repository/blob/main/.github/update_templates_review.yml)
34-
- [Update Liquid Templates - Production](https://github.com/silverfin/example_liquid_repository/blob/main/.github/update_templates_production.yml)
35-
36-
### Setup
37-
38-
- Create `SF_API_CLIENT_ID` & `SF_API_SECRET` secrets.
39-
- Create a secret named `CONFIG_JSON` where you replicate a local `~/.silverfin/config.json`. It is important to note that the token's pair that this Action is going to use shouldn't be also used by other users, since it will be revoked eventually.
40-
- Set variables named `FIRM_ID_REVIEW`, `FIRM_ID_PRODUCTION`.
41-
- Create a [Personal Access Token](https://github.com/settings/personal-access-tokens/new).
42-
- Set it to only have access to the repository needed and nothing else.
43-
- Limit it's scope as much as possible.
44-
- Permissions:
45-
- Environments: `Read and Write`
46-
- Metadata: `Read-only`
47-
- Pull requests: `Read and Write`
48-
- Secrets: `Read and Write`
49-
- Store it as a secret named `REPO_ACCESS_TOKEN`
50-
51-
### Behaviour
52-
53-
As they are defined right now, these workflows will be triggered in different situations:
54-
55-
- "run_tests":
56-
- Use: automatically runs the liquid tests of the updated reconciliations as well as the liquid tests of all the reconciliations linked to an updated shared part.
57-
- Run: will be run when any change is made in an existing Pull Request (created, updated, closed). It will use take the first firm ID from the config.json from the reconciliation to specify in which firm the liquid tests will be run.
58-
- "update_templates_review":
59-
- Use: automatically updates the changes liquid templates to the firm specified in the variable "FIRM_ID_REVIEW", which is the firm where the functional review will be done after the main development / code review is over.
60-
- Run: will be run when a label named "2-functional-review" is added to a PR and on every subsequent push to this PR while this label is still added. It will use the variable "FIRM_ID_REVIEW" to establish to which firm the updates will be pushed.
61-
- "update_templates_production":
62-
- Use: automatically updates the changes liquid templates to the firm specified in the variable "FIRM_ID_PRODUCTION", which is the firm where a 'custom template' copy of all the templates exist which are equal to the partner templates. This is the firm where the templates needs to copied from to partner. Will automatically remove all previously added labels and add the label '3-deploy-to-partner'.
63-
- Run: will be run when a PR is closed and merged to the main branch. It will use the variable "FIRM_ID_PRODUCTION" to establish to which firm the updates will be pushed.
64-
- "add_shared_parts_review":
65-
- Use: automatically adds the shared parts to the firm specified in the variable "FIRM_ID_REVIEW", which is the firm where the functional review will be done after the main development / code review is over.
66-
- Run: will be run when a label named "add-shared-parts-review-firm" is added to a PR. It will use the variable "FIRM_ID_REVIEW" to establish to which firm the updates will be pushed. Once it's finished, labeles will be automatically removed and a comment will be inserted in the PR.
67-
- "add_shared_parts_production":
68-
- Use: automatically adds the shared parts to the firm specified in the variable "FIRM_ID_PRODUCTION". This is the firm where the templates needs to copied from to partner. Once it's finished, labeles will be automatically removed and a comment will be inserted in the PR.
30+
# Github Actions documentation
31+
32+
The document will go over all the Github Actions that currently automate a couple of tasks in the Silverfin development workflow. All the actions are designed to be reused across multiple market repositories.
33+
34+
35+
## Table of Contents
36+
37+
* [Overview](https://silverfin.quip.com/avPDA9TrpJ9Y#temp:C:EBfa4cff673955d42e9a609fab12)
38+
* [Individual Action Documentation](https://silverfin.quip.com/avPDA9TrpJ9Y#temp:C:EBf5d38766349a742b78f139ee4d)
39+
* [Label management](https://silverfin.quip.com/avPDA9TrpJ9Y#temp:C:EBfda115c3c17e34b4c833cb4b0a)
40+
* [Add Code Review Label (add_code_review_label.yml)](https://silverfin.quip.com/avPDA9TrpJ9Y#temp:C:EBfce44f57a01564acd95f8c0c98)
41+
* [Remove Code Review Label (remove_code_review_label.yml)](https://silverfin.quip.com/avPDA9TrpJ9Y#temp:C:EBf2828559422d84087b81255dc8)
42+
* [Authentication](https://silverfin.quip.com/avPDA9TrpJ9Y#temp:C:EBf4f743db4b6854130af8693671)
43+
* [Check authentication (check_auth.yml)](https://silverfin.quip.com/avPDA9TrpJ9Y#temp:C:EBf73af65c6455e4bb6a62454b15)
44+
* [Testing](https://silverfin.quip.com/avPDA9TrpJ9Y#temp:C:EBf13d6dbd0df1e4450b3b22691c)
45+
* [Check YAML files (check_tests.yml)](https://silverfin.quip.com/avPDA9TrpJ9Y#temp:C:EBf931fa1547b4b419d940464f89)
46+
* [Run liquid tests (run_tests.yml)](https://silverfin.quip.com/avPDA9TrpJ9Y#temp:C:EBfa4878bb5baac49cbb0c39d927)
47+
* [Slack updates](https://silverfin.quip.com/avPDA9TrpJ9Y#temp:C:EBfc9ca89d4b174494391ba075c5)
48+
* [Automated slack update (slack_changelog.yml)](https://silverfin.quip.com/avPDA9TrpJ9Y#temp:C:EBf862cf4257e68475d8b47891c6)
49+
50+
51+
## Overview
52+
53+
All Github Actions are designed to be reused across multiple market repositories. As a result, they are stored in a specific repository in Github: [BSO Github Actions](https://github.com/silverfin/bso_github_actions). If an action needs to be added to a specific repository, these generic actions/workflows can be linked.
54+
55+
Currently, there are three groups of actions available:
56+
57+
* Label management: Add/remove code review labels automatically
58+
* Authentication: Check and refresh Silverfin API tokens
59+
* Testing: Validate YAML files and run liquid tests
60+
61+
62+
63+
## Individual Action Documentation
64+
65+
### Label management
66+
67+
#### Add Code Review Label `(add_code_review_label.yml)`
68+
69+
_Description_:
70+
The workflow will automatically add a `code-review` label to pull requests when a review is requested.
71+
72+
_Trigger_:
73+
74+
* A reviewer is assigned/requested on any PR
75+
* A draft PR is converted to "Ready for review"
76+
77+
#### Remove Code Review Label `(remove_code_review_label.yml)`
78+
79+
_Description_:
80+
Automatically removes the "code-review" label from pull requests when review comments are provided. It will only execute if the review contains actual comments and the commenter is NOT CodeRabbit.
81+
82+
_Trigger_:
83+
84+
* A complete PR review (any type: approve, request changes, comment) is submitted
85+
* An individual line comment has been submitted during the review
86+
87+
88+
89+
### Authentication
90+
91+
#### Check authentication `(check_auth.yml)`
92+
93+
_Description_:
94+
Refreshes Silverfin API tokens to ensure authentication remains valid for subsequent operations.
95+
96+
_Trigger_:
97+
98+
* The authentication workflow is run before the `run-tests` workflow to make sure that we always have the correct authentication before communicating with the platform.
99+
100+
101+
_Steps:_
102+
103+
* Installs the latest silverfin-cli version
104+
* Loads the CONFIG_JSON file from the secrets
105+
* Refreshes the tokens for all configured firms
106+
* Updates the CONFIG_JSON file secret with the refreshed tokens
107+
108+
109+
_Prerequisites_:
110+
111+
* `SF_API_CLIENT_ID`: Silverfin API client ID
112+
* `SF_API_SECRET`: Silverfin API secret
113+
* `CONFIG_JSON`: Silverfin configuration file content
114+
* `REPO_ACCESS_TOKEN`: GitHub personal access token
115+
116+
117+
118+
### Testing
119+
120+
#### Check YAML files `(check_tests.yml)`
121+
122+
_Description:_
123+
Validates that at least 1 `.yaml/.yml` file has been added or updated when changes are made to templates. This can be by-passed by adding the `no-test-required` to the pull request.
124+
125+
_Trigger:_
126+
127+
* Every time new commits are pushed to a PR
128+
* When labels are added (important for the `no-test-required` bypass logic)
129+
* When labels are removed (re-enables validation if `no-test-required` was removed)
130+
131+
#### Run liquid tests `(run_tests.yml)`
132+
133+
_Description:_
134+
Executes liquid tests for updated reconciliations and reconciliations that use updated shared parts.
135+
136+
_Trigger_:
137+
138+
* On every pull request to any branch (comprehensive testing)
139+
* When code is pushed directly to main (post-merge validation)
140+
* Runs on PR creation, updates (commits), and rebasing/merging actions
141+
142+
143+
_Steps:_
144+
145+
* Calls `check_auth.yml` to refresh tokens
146+
* Identifies changed liquid/config files
147+
* Determines which templates need testing
148+
* Runs liquid tests using silverfin-cli `run-test` command
149+
* Supports multiple firm ID selection strategies ℹ️
150+
151+
152+
_Test firm options:_
153+
There is a certain priority when it comes to test firm id’s. Users do have some options to configure which test firm is used for the liquid tests.
154+
155+
156+
1. **Template-specific test firm id**
157+
158+
This is the most specific option that is available on a template by template basis. An additional attribute `test_firm_id` can be added to the `config.json` file. That firm will always get priority over the other two options.
159+
160+
161+
1. **Github test firm id**
162+
163+
If the `test_firm_id` is not used for a specific handle, the Github action will look for a Github environment variable `SF_TEST_FIRM_ID`. This variable can be defined on [this page](https://github.com/silverfin/be_market/settings/variables/actions) (link to BE market) and will be used for every template within the market repo (so not template specific).
164+
165+
166+
1. **Default test firm id**
167+
168+
If none of the above options is used/defined, we will fall back to the default option: the first firm id that is present in the `config.json` file. This is again template specific, but the order cannot be changed (the smallest firm id number will always be on top).
169+
170+
171+
172+
### Slack updates
173+
174+
#### Automated slack update (`slack_changelog.yml`)
175+
176+
_Description_:
177+
Posts a changelog update to Slack when a pull request is merged into the `main` branch.
178+
179+
_Trigger:_
180+
181+
* A pull request targeting `main` is closed
182+
* Only proceeds if the pull request was actually merged (not just closed)
183+
184+
185+
_Steps:_
186+
187+
* Checks that the closed PR was merged
188+
* Inherits repository/organization secrets and sends the Slack notification for the merged PR
189+
190+
191+
_Prerequisites:_
192+
193+
* Set up a Slack workflow in the Slack settings.
194+
* [UK](https://slack.com/shortcuts/Ft09PPKBHW5N/f0d53e634f6fccff7335148ac0eab5d8)
195+
* [NL](https://slack.com/shortcuts/Ft09MT6C2CKW/c8cb614e95f1192fdbeb264361d04f73)
196+
* [LU](https://slack.com/shortcuts/Ft09ML70CL94/1a767ec100c7340772e48c84c24665fa)
197+
* [BE](https://slack.com/shortcuts/Ft09CP21L86M/ed8f5f30038e6ecca4adf2d01df996ef)
198+
* This workflow will then generate a URL, which is called a webhook.
199+
* The webhook from the workflow should be stored in an environment variable in the market specific repository: `SLACK_WEBHOOK_URL`
200+
* The Github action will create a text object (containing the formatted message) and will post this to the Slack webhook. This will then create the message in a pre-defined channel.

0 commit comments

Comments
 (0)