Feature/add new process

.github/workflows/ci.yml

@@ -0,0 +1,29 @@
+name: CI
+
+on:
+  push:
+    branches: ["main"]
+  pull_request:
+    branches: ["main"]
+
+concurrency:
+  group: ${{ github.workflow }}-${{ github.ref }}
+  cancel-in-progress: false
+
+jobs:
+  dp-operations-lint:
+    runs-on: ubuntu-latest
+    steps:
+    - uses: actions/checkout@v5
+      with:
+        fetch-depth: 0
+    - uses: tj-actions/changed-files@v46
+      id: changed-files
+      with:
+        files: '**/*.md'
+        separator: ","
+    - uses: DavidAnson/markdownlint-cli2-action@v20
+      if: steps.changed-files.outputs.any_changed == 'true'
+      with:
+        globs: ${{ steps.changed-files.outputs.all_changed_files }}
+        separator: ","

.markdownlint-cli2.yaml

@@ -0,0 +1,7 @@
+---
+config:
+  line-length: false
+  ul-style:
+    style: dash
+ignores:
+  - "LICENSE.md"

.pre-commit-config.yaml

@@ -0,0 +1,35 @@
+# Keeping the hooks versions up to date can be done by running `pre-commit autoupdate` validate that the examples still pass correctly before pushing the updated version changes
+repos:
+- repo: https://github.com/pre-commit/pre-commit-hooks
+  rev: v5.0.0
+  hooks: # Available hooks https://github.com/pre-commit/pre-commit-hooks/blob/main/README.md
+    # Git style
+    - id: check-added-large-files # prevents giant files from being committed.
+    - id: check-merge-conflict # checks for files that contain merge conflict strings.
+    - id: check-vcs-permalinks # ensures that links to vcs websites are permalinks.
+    - id: no-commit-to-branch # Protect specific branches from direct commits.
+      args: [--branch, main] # Protected in the repo config. but this will prevent you even getting that far
+    # Common errors
+    - id: end-of-file-fixer # Ensures that a file is either empty, or ends with one newline.
+    - id: trailing-whitespace # Trims trailing whitespace.
+      args: [--markdown-linebreak-ext=md] # Preserve hard line breaks in MD files
+    - id: check-yaml # Attempts to load all yaml files to verify syntax.
+    - id: check-executables-have-shebangs # Checks that non-binary executables have a proper shebang.
+    # Cross platform
+    - id: check-case-conflict # Check for files with names that would conflict on a case-insensitive filesystem like MacOS HFS+ or Windows FAT.
+    - id: mixed-line-ending # Replaces or checks mixed line ending.
+      args: [--fix=lf] # Forces to replace line ending with LF
+    # Security
+    - id: detect-aws-credentials # Checks for the existence of AWS secrets that you have set up with the AWS CLI.
+      args: ['--allow-missing-credentials'] # Allow hook to pass when no credentials are detected.
+    - id: detect-private-key # Checks for the existence of private keys.
+
+- repo: https://github.com/zricethezav/gitleaks
+  rev: v8.23.3
+  hooks:
+    - id: gitleaks
+
+- repo: https://github.com/DavidAnson/markdownlint-cli2
+  rev: v0.18.1
+  hooks:
+    - id: markdownlint-cli2

CONTRIBUTING.md

@@ -0,0 +1,49 @@
+# Contributing guidelines
+
+## Git workflow
+
+- We use trunk based development - create a feature branch from `main`, e.g. `feature/new-feature`
+- Pull requests must contain a succinct, clear summary of what the user need is driving this document change
+- Ensure your branch contains logical atomic commits following our [commit standards](https://github.com/ONSdigital/dp-standards/blob/main/COMMIT_STANDARDS.md) before submitting a pull request
+- You may rebase your branch after feedback if it's to include relevant updates from the main branch. We prefer a rebase here to a merge commit as we prefer a clean and straight history on develop with discrete merge commits for changes
+
+## Pre-commit
+
+We encourage the use of [pre-commit](https://pre-commit.com/) locally, this reduces the amount of common mistakes and engineers can just focus on reviewing the actual changes.
+
+```sh
+# Install pre-commit
+brew install pre-commit
+# This will enable pre-commit to run every time you git commit
+pre-commit install
+```
+
+If you want to do an adhoc run of pre-commit
+
+⚠️ This will only run on files that are staged in git
+
+```sh
+pre-commit run --all-files
+```
+
+If you want to commit and skip checks
+
+```sh
+git commit --no-verify -m "some message"
+```
+
+## Markdown linting
+
+This respository uses [markdown linting](https://github.com/DavidAnson/markdownlint-cli2) for all PRs.
+
+To install:
+
+```sh
+    brew install markdownlint-cli2
+```
+
+To run:
+
+```sh
+    markdownlint-cli2 **/*.md
+```

guides/CONTRIBUTING.md

@@ -2,34 +2,40 @@
 
 ## Development work
 
-* As a first step, GPG key setup is required in order to contribute:
+We currently have two different processes in place as we are transitioning between them.
+
+The below is true for both approaches, see branching strategy below for the differences.
+
+- As a first step, GPG key setup is required in order to contribute:
   instructions on setup can be found in the [GPG Guide](https://github.com/ONSdigital/dp-operations/blob/main/guides/gpg.md)
-* We use [git-flow](https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow) -
-  create a feature or fix branch from `develop`, e.g. `feature/<new-feature>`, `fix/<new-fix>`. Alternatively, create a hotfix branch from master e.g. `hot-fix/<new-hotfix>`.
-* Pull requests must use the pull request template found in each repo. Each section must contain the following:
-  * 'What' - a succinct, clear summary of what the user-need is that is driving this feature change,
-  * 'How to review' - a step-by-step guide or set of guides that detail how a reviewer can test and verify the changes made
-  * 'Who can review' - a list of the most appropriate people to review the pull request,
+- Pull requests must use the pull request template found in each repo. Each section must contain the following:
+  - 'What' - a succinct, clear summary of what the user-need is that is driving this feature change,
+  - 'How to review' - a step-by-step guide or set of guides that detail how a reviewer can test and verify the changes made
+  - 'Who can review' - a list of the most appropriate people to review the pull request,
     e.g. if on a frontend application, a member of the frontend team should review; likewise for backend and platform.
     If the changes are critical or are likely to have severe side-effects then the Tech Lead should review.
-* Ensure your branch contains logical atomic commits before sending a pull request - follow the [GDS Way styleguide](https://gds-way.digital.cabinet-office.gov.uk/standards/source-code/working-with-git.html#commits)
-* You may rebase your branch after feedback if it's to include relevant updates from the `develop` branch. We prefer a rebase here to a merge commit as we
-  prefer a clean and straight history on the `develop` branch, with discrete merge commits for features
-* It is advised to squash commits before pushing to a remote repository
+- Ensure your branch contains logical atomic commits before sending a pull request - follow the [GDS Way styleguide](https://gds-way.digital.cabinet-office.gov.uk/standards/source-code/working-with-git.html#commits)
+- You may rebase your branch after feedback if it's to include relevant updates from the upstream branch. We prefer a rebase here to a merge commit as we
+  prefer a clean and straight history on protected branches, with discrete merge commits for features
+- It is advised to squash commits before pushing to a remote repository
 
-----
+### New branching strategy
 
-## Releasing
+We use trunk based development - create a feature branch from `main`, e.g. `feature/new-feature`
 
-* For instructions on how to release work, read the [Releases guidelines](RELEASES.md)
+### Old branching strategy
+
+We use [git-flow](https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow) - create a feature or fix branch from `develop`, e.g. `feature/<new-feature>`, `fix/<new-fix>`. Alternatively, create a hotfix branch from master e.g. `hot-fix/<new-hotfix>`.
+
+## Releasing
 
-----
+For instructions on how to release work, read the [Releases guidelines](RELEASES.md)
 
 ## Access to Environments
 
 ### Note: if you get a 404 error for any of the below links, then you need to be added to the `ONSdigital` organisation in GitHub
 
-* For direct access to the environments
-  * Setup your [AWS credentials](AWS_CREDENTIALS.md)
-  * Configure your [SSH access](https://github.com/ONSdigital/dp-operations/blob/main/guides/ssh-access.md)
-  * [Ansible](https://github.com/ONSdigital/dp-ci/tree/master/ansible#prerequisites) is required for provisioning to environments
+- For direct access to the environments
+  - Setup your [AWS credentials](AWS_CREDENTIALS.md)
+  - Configure your [SSH access](https://github.com/ONSdigital/dp-operations/blob/main/guides/ssh-access.md)
+  - [Ansible](https://github.com/ONSdigital/dp-ci/tree/master/ansible#prerequisites) is required for provisioning to environments