actions-workflow-samples VS commitlint

GitHub Actions for Azure (official examples): https://github.com/Azure/actions-workflow-samples

appcontent.yml - Used to deploy my app content to the Azure App Service. Using this sample provided by Microsoft, with very minor modifications.

It's using GitHub Secrets. This guide helps: https://github.com/Azure/actions-workflow-samples/blob/master/assets/create-secrets-for-GitHub-workflows.md

For this exercise we need a personal access token from github. To ensure that the action has access to the GitHub token which you, by the way, should never expose to the public - we will place it in the secrets of the repo.

First we'll need to make some repo secrets. Here's a nice guide from Azure explaining how to do just that. It isn't difficult at all.

Add Actions secrets for the FTPS credentials. In our example the secret names are WP_USER and WP_PASSWORD.

Yep. For the projects I’ve worked on, the Azure Functions for scheduling were in their own `functions` folder at the root of the repository. Upon successful deployment of the main app, we’d then deploy the functions. Aside from that deployment happening after the main app’s, we use the same deployment configuration as the official example for GitHub Actions with Python functions: https://github.com/Azure/actions-workflow-samples/blob/master/FunctionApp/linux-python-functionapp-on-azure.yml.

We have 1 user that we use for deployment. We keep the username and password of this user in a Secret (all platforms support some form of secrets, here is some docs on Github Actions specifically).

I followed the official documentation (Link) and used the pre-defined template and it worked out of the box.

Apart from these we also need to enforce standards for all our commit messages(commit-lint).

There are many features of commitlint that I can't mention one by one, as well as installation guide. To know the detail you can directly access https://github.com/conventional-changelog/commitlint.

These commit message prefixes can help to provide context and organization in a project's version control history, making it easier to understand and track changes over time. Note: if you want to force these rules on commit messages, here is a commit linting lib for you. Commitlint

Commit Lint

I personally find it quite useful to enforce a uniform commit style. commitlint pairs well with husky.

⧗ input: Set up Conventional Commits using Husky and commitlint ✖ subject may not be empty [subject-empty] ✖ type may not be empty [type-empty] ✖ found 2 problems, 0 warnings ⓘ Get help: https://github.com/conventional-changelog/commitlint/#what-is-commitlint husky - commit-msg hook exited with code 1 (error)

Can setup tools like Commitlint to add hooks that will reject a commit message if it is invalid, but if you format a commit message incorrectly it simply closes the commit buffer and returns to git status, meaning you have to retype out your commit message, which is obviously less than ideal.

✅ Angular 14 ✅ Angular Material ✅ Unit Testing with Jest ✅ End-to-End Testing with TestCafé ✅ Internationalization with Transloco ✅ Auto documentation with Compodoc ✅ Analyse your project with source-map-explorer ✅ Docker ✅ ESLint ✅ Prettier ✅ Commit Linting