Skip to content

Commit

Permalink
feat: check markdown links on the CI (#958)
Browse files Browse the repository at this point in the history 
## Proposed change

While exploring the documentation, I've noticed some broken link.

I found
[markdown-link-check](https://github.com/marketplace/actions/markdown-link-check)
which does a good job for both relative and external links.

Ideally we could have 2 separate runs: one on modified files on PRs and
a second one triggered every month on all `md` files to check for broken
external links.
  • Loading branch information
@vscaiceanu-1a
vscaiceanu-1a authored Jan 8, 2024
2 parents a5fa465 + 0e643a8 commit 3403135
Show file tree
Hide file tree
Showing 27 changed files with 182 additions and 157 deletions.
8 changes: 8 additions & 0 deletions .github/markdown.links.config.json
View file
Original file line number Diff line number Diff line change
@@ -0,0 +1,8 @@
{
"replacementPatterns": [
{
"pattern": "/%40",
"replacement": "/@"
}
]
}
10 changes: 10 additions & 0 deletions .github/workflows/code-check.yml
View file
Original file line number Diff line number Diff line change
Expand Up @@ -22,6 +22,16 @@ env:
NX_SKIP_NX_CACHE: ${{ inputs.skipNxCache }}

jobs:
markdown-link-check:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@master
- uses: gaurav-nelson/github-action-markdown-link-check@v1
with:
base-branch: 'main'
config-file: '.github/markdown.links.config.json'
folder-path: 'packages/,apps/,tools/'

test:
strategy:
fail-fast: false
Expand Down
2 changes: 1 addition & 1 deletion CONTRIBUTING.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -61,7 +61,7 @@ To ease the process, we are providing a set of:

* [Editors configuration](.editorconfig)
* [Linters configuration](./packages/@o3r/eslint-config-otter/README.md)
* [Component generator](./docs/core/OTTER_ANGULAR_TOOLS.md#schematics) (and more)
* [Component generator](./packages/@o3r/core/README.md#generators) (and more)

## Code review process

Expand Down
5 changes: 4 additions & 1 deletion apps/vscode-extension/package.json
View file
Original file line number Diff line number Diff line change
Expand Up @@ -41,7 +41,10 @@
},
"otter.styling.variable.types": {
"type": "array",
"default": ["color", "string"],
"default": [
"color",
"string"
],
"items": {
"type": "string"
}
Expand Down
6 changes: 3 additions & 3 deletions docs/README.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -18,7 +18,7 @@ The documentation is sorted by topic but in the table below, you shall find the
| @o3r/extractors | Utilities to extract your application metadata to interact with your CMS | @o3r/core <br/> @o3r/dev-tools | |
| @o3r/forms | Utilities to enhance angular form (asynchronous decorator, additional validator, error store...) | @o3r/core <br/> @o3r/dev-tools | [README](./forms/README.md) <br/> [FORM_ERRORS](./forms/FORM_ERRORS.md) <br/> [FORM_STRUCTURE](./forms/FORM_STRUCTURE.md) <br/> [FORM_SUBMIT_AND_INTERCOMMUNICATION](./forms/FORM_SUBMIT_AND_INTERCOMMUNICATION.md) <br/> [FORM_VALIDATION](./forms/FORM_VALIDATION.md) |
| @o3r/localization | Provide a fallback language/translation support and debug tools | @o3r/core <br/> @o3r/dev-tools | [LOCALIZATION](./localization/LOCALIZATION.md) <br/> [CMS_ADAPTERS](./cms-adapters/CMS_ADAPTERS.md) |
| @o3r/logger | Bridge to target different logger (logrocket, fullstory, smartlook) with a common interface | N/A | [LOGS](./logger/LOGS.md) |
| @o3r/logger | Bridge to target different logger (logrocket, fullstory, smartlook) with a common interface | N/A | [LOGS](./logger/LOGS.md) |
| @o3r/mobile | Helpers and store to integrate Capacitor into your Otter application. <br/> Integration with the pCloudy API for e2e testing on real devices. | @o3r/core <br/> @o3r/logger | |
| @o3r/routing | Module to configure an Otter application's routing (POST parameter management, preloading strategy, guard recommendation) | @o3r/core <br/> @o3r/dev-tools | [REQUEST_PARAMETERS_SERVICE](./routing/REQUEST_PARAMETERS_SERVICE.md) <br/> [ROUTING](./routing/ROUTING.md) <br/> [APP_SERVER_ROUTING](./routing/APP_SERVER_ROUTING.md) |
| @o3r/rules-engine | Rule engine executed on your Otter application to customize your application translations, placeholders and configs based on a json file generated by your CMS | @o3r/components <br/> @o3r/configuration <br/> @o3r/core <br/> @o3r/dev-tools <br/> @o3r/dynamic-content <br/> @o3r/extractors <br/> @o3r/localization <br/> @o3r/logger <br/> @o3r/styling | [how-it-works](./rules-engine/how-it-works.md) <br/> [how-to-use](./rules-engine/how-to-use.md) <br/> [examples](./rules-engine/examples.md) <br/> [facts](./rules-engine/facts.md) <br/> [operators](./rules-engine/operators.md) <br/> [rule](./rules-engine/rule.md) <br/> [ruleset](./rules-engine/ruleset.md) <br/> [CMS_ADAPTERS](./cms-adapters/CMS_ADAPTERS.md) |
Expand All @@ -28,5 +28,5 @@ The documentation is sorted by topic but in the table below, you shall find the
| @o3r/styling | Styling framework to apply a theme on an Otter application at build time and runtime to support CMS customization | @o3r/core <br/> @o3r/dynamic-content <br/> @o3r/extractors <br/> @o3r/schematics | [THEME](./styling/THEME.md) <br/> [TYPOGRAPHY](./styling/TYPOGRAPHY.md) <br/> [CMS_ADAPTERS](./cms-adapters/CMS_ADAPTERS.md) |
| @o3r/testing | Testing (e2e, unit test) utilities to help you build your own E2E pipeline integrating visual testing | @o3r/localization <br/> @o3r/schematics | [POST_MESSAGE_INTERCEPTOR](./testing/POST_MESSAGE_INTERCEPTOR.md) <br/> [UNIT_TESTS_SETUP](./testing/UNIT_TESTS_SETUP.md) |
| @o3r/third-party | Bridge to communicate with third parties via an iFrame solution | N/A | [A/B Testing](./ab-testing/AB_TESTING.md) |
| @o3r/vscode-extension | Various in house VSCode extensions to help you with the development of your Otter application with this IDE (automated generated Otter components etc.) | N/A | [vscode-extension](./vscode-extension.md) |
| @o3r/eslint-config-otter | Recommended eslint configuration for Otter project | @o3r/eslint-plugin | [eslint-config](./linter/eslint-config.md) |
| @o3r/vscode-extension | Various in house VSCode extensions to help you with the development of your Otter application with this IDE (automated generated Otter components etc.) | N/A | [vscode-extension](../apps/vscode-extension/README.md) |
| @o3r/eslint-config-otter | Recommended eslint configuration for Otter project | @o3r/eslint-plugin | [eslint-config](./linter/eslint-config.md) |
37 changes: 14 additions & 23 deletions docs/core/DEVELOPER.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -3,15 +3,15 @@

## Where to define the ng-update migrations?

To be recognized by the __ng-cli as update schematics__, we have to define our migrations schematics in
To be recognized by the __ng-cli as update schematics__, we have to define our migrations schematics in
__package.json__, _ng-update_ section of the package which contains the updates, in our case __@o3r/core__
```json
"ng-update": {
"migrations": "./migration.json"
}
```

The content of migration.json is as follows:
The content of migration.json is as follows:
ex:
```json
{
Expand All @@ -25,32 +25,32 @@ ex:
"migration-v3_2": {
"version": "3.2.0-alpha.0", // version to update to
"description": "Updates of the Otter Library v3.2.x",
"factory": "./schematics/ng-update/index#updateV3_2" // relative path to the schematics factory function to execute
"factory": "./schematics/ng-update/index#updateV3_2" // relative path to the schematics factory function to execute
}
}
}
```
```

When we run the update on _@o3r/core_ (```yarn ng update @o3r/core```) in our app, ng-cli will install the latest version of @o3r/core and
it will check the ng-update section in the package.json of the new installed version, to see if there are updates to execute.
Based on the starting version of @o3r/core and the new installed one, the cli will run the schematics which are between these 2 versions from migration.json
Here are 2 scenarios:
When we run the update on _@o3r/core_ (```yarn ng update @o3r/core```) in our app, ng-cli will install the latest version of @o3r/core and
it will check the ng-update section in the package.json of the new installed version, to see if there are updates to execute.
Based on the starting version of @o3r/core and the new installed one, the cli will run the schematics which are between these 2 versions from migration.json
Here are 2 scenarios:
### Scenario 1
- Application in otter 3.0, latest stable version of otter is 3.2
- Application in otter 3.0, latest stable version of otter is 3.2

Based on the above _migration.json_ the cli will run __migration-v3__ and __migration-v3_2__ because the versions '3.1.0-alpha.0' and '3.2.0-alpha.0' defined in migration.json are between 3.0 (old version) and 3.2 (latest stable)

### Scenario 2
- Application in otter 3.1, latest stable version of otter is 3.2
- Application in otter 3.1, latest stable version of otter is 3.2

Based on the above _migration.json_ the cli will run __migration-v3_2__ because the version '3.2.0-alpha.0' defined in migration.json is the only one between 3.0 (old version) and 3.2 (latest stable)

## Development time

To be easier to test in local, when we need to create/update schematics, we can use the schematics cli.
1. install @angular-devkit\schematics-cli on the app, if needed (no need to commit the change)
2. link (yarn link or cpx) @o3r/core in the app
3. run:
2. link (yarn link or cpx) @o3r/core in the app
3. run:
```node ./node_modules/@angular-devkit/schematics-cli/bin/schematics.js ./node_modules/@o3r/core/collection.json:update-otter --dry-run=false --force```

One mention for step 3 is that you have to add a new entry in _@o3r/core/collection.json_ to point to the update schematic
Expand All @@ -62,15 +62,6 @@ One mention for step 3 is that you have to add a new entry in _@o3r/core/collect
```
No need to commit this change.

## Testing your schematic with the PR version number

When you have done the development on the schematic, next steps are required to test that your schematic is working with the normal way of running it (not the way used in dev chapter)
Steps:
- all steps are executed at app level;
1. modify _.npmrc_ of the app to target the _otter-pr_ versions
@o3r:registry=https://pkgs.dev.azure.com/AmadeusDigitalAirline/Otter/_packaging/otter-pr/npm/registry/ (don't forget auth tokens)

2. run: yarn ng update @o3r/core@prVersion --force
ex: ``` yarn ng update @o3r/[email protected] --force```
## Testing your schematic with the PR version number

The command above will run all schematics update for all packages defined in "ng-update" -> "packageGroup" section in `package.json` file of _@o3r/core_
Please refer to the [Verdaccio](../../.verdaccio/README.md) setup.
2 changes: 1 addition & 1 deletion docs/core/START_NEW_APPLICATION.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -45,7 +45,7 @@ export class AppModule { }
```

You will also find recommendations for your application such accessibility configuration like the
[Application Reduced Motion](docs/application/REDUCED_MOTION.md)
[Application Reduced Motion](../application/REDUCED_MOTION.md)

It will also update your ``angular.json`` with the feature enabled for your project. This will configure the different generators
to create components and services consistent with your project.
Expand Down
Loading

0 comments on commit 3403135

Please sign in to comment.