Skip to content

Add pipeline best practices, local development, and release categorisation guidance - #610

Draft
zc-hmcts wants to merge 26 commits into
mainfrom
pipeline_practices
Draft

Add pipeline best practices, local development, and release categorisation guidance#610
zc-hmcts wants to merge 26 commits into
mainfrom
pipeline_practices

Conversation

@zc-hmcts

Copy link
Copy Markdown
Contributor

No description provided.

@github-actions

This comment has been minimized.

@github-actions

This comment has been minimized.

@github-actions

This comment has been minimized.

@github-actions

This comment has been minimized.

@zc-hmcts zc-hmcts changed the title Add pipeline best practices and local development guidance Add pipeline best practices, local development, and release categorisation guidance Jul 21, 2026
@github-actions

This comment has been minimized.

-Danalyzer.retirejs.enabled=false \
-Danalyzer.ossindex.enabled=false \
dependencyCheckAggregate
```

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Jotting down some of my initial thoughts and playing devil's advocate a bit:

  • the extra load on the server could affect pipelines, slowing them down
  • increasing the SKU would incur more cost, something we can account for but needs considered
  • if we did this, we'd probably want a read-only user and we'd need the ability for developers to be able to retrieve the connection string for that user
  • that could be a too widely publicised secret to be using
  • perhaps instructions on how to spin up a local db would give us the best of both worlds

terraform init
terraform validate
terraform plan
```

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We'd need to overhaul our terraform state setup to allow developers read access. I'd be in favour of that, I've had the need to run some local terraform lately and found the lack of a good access mechanism frustrating.

You could argue this means developers have access to values such as secrets from state files but the same developers would probably have access to key vaults anyway as long as it's not production.

Solutionising a bit but want to make the note anyway about what we do about ensuring there's not blanket access to state files. I'm sure some things developers don't need to access would get included in a scenario where we allow read access blob wide for state files.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On the other hand, I would say terraform is not the major thing developers need to run locally and the commands are fairly complex with all the variables if you're not familiar with the setup

@github-actions

Copy link
Copy Markdown

@check-spelling-bot Report

🔴 Please review

See the 📂 files view, the 📜action log, or 📝 job summary for details.

Unrecognized words (11)
Danalyzer
Ddata
Ddependency
Dnvd
ossindex
OWASPDB
Pnvd
Qube
retirejs
tfenv
validforhours
These words are not needed and should be removed devcontainers

To accept these unrecognized words as correct and remove the previously acknowledged and now absent words, you could run the following commands

... in a clone of the git@github.com:hmcts/hmcts.github.io.git repository
on the pipeline_practices branch (ℹ️ how do I use this?):

curl -s -S -L 'https://raw.githubusercontent.com/check-spelling/check-spelling/v0.0.23/apply.pl' |
perl - 'https://github.com/hmcts/hmcts.github.io/actions/runs/29998075392/attempts/1'
Warnings (1)

See the 📂 files view, the 📜action log, or 📝 job summary for details.

⚠️ Warnings Count
⚠️ no-newline-at-eof 1

See ⚠️ Event descriptions for more information.


🖊️ Please consider adding a word to the allow list if it is flagged as a spelling error but is genuinely used within the project.
🤔 Think we might see a flagged mistake in another PR in the future? Please consider adding it as an expected pattern.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants