Add securityContext to copy-responses init container

[subigre]

This PR adds the missing securityContext attribute on copy-responses similarly to how it is done on wiremock and copy-mappings containers

References

Closes #42

Submitter checklist

• Recommended: Join WireMock Slack to get any help in #help-contributing or a project-specific channel like #wiremock-java
• The PR request is well described and justified, including the body and the references
• The PR title represents the desired changelog entry
• The repository's code style is followed (see the contributing guide)
• Test coverage that demonstrates that the change works as expected
• For new features, there's necessary documentation in this pull request or in a subsequent PR to wiremock.org

[DanielFran]

Good catch!

[subigre]

Just bumped the chart version that I forgot to do in the previous commit 😞
I wasn’t sure if I can also update the app version at the same time as WireMock version is 3.9.1 now, or if it is better to do it in a separate PR as it is not related to the initial scope?

[gitkent]

Just bumped the chart version that I forgot to do in the previous commit 😞 I wasn’t sure if I can also update the app version at the same time as WireMock version is 3.9.1 now, or if it is better to do it in a separate PR as it is not related to the initial scope?

Leave app version as is.

Just bumped the chart version that I forgot to do in the previous commit 😞 I wasn’t sure if I can also update the app version at the same time as WireMock version is 3.9.1 now, or if it is better to do it in a separate PR as it is not related to the initial scope?

@subigre leave app version as is. For chart version can you please change to 1.1.0 as we want to follow semantic versioning with <breaking-change>.<feature>.<bugfix>

Adding a new fields in deployment is a feature. Thanks 😊

[gitkent]

Please update version to 1.1.0

[gitkent]

Hi @subigre can you also please publish the chart with version 1.1.0, otherwise helm install will fail.

Thanks 😊

[subigre]

Hello @gitkent, to be honest, I didn’t understand why the charts are in the master branch.
I only used it with OCI registries so far, but aren't automatically packaged and pushed by the use of helm/chart-releaser-action in your release workflow?

[subigre]

Done anyway

[DanielFran]

@gitkent index has not been updated with the new version 1.1.0

[gitkent]

@gitkent index has not been updated with the new version 1.1.0

@DanielFran thanks for pointing out. Please review this #45

[subigre]

It is already up to date in the gh-pages branches
https://github.com/wiremock/helm-charts/blob/gh-pages/index.yaml#L4-L31

Trying to understand, what is the purpose of adding the index.yaml in the main branch as well? the chart-releaser tool already handles it for us by default?

[gitkent]

It is already up to date in the gh-pages branches https://github.com/wiremock/helm-charts/blob/gh-pages/index.yaml#L4-L31

Trying to understand, what is the purpose of adding the index.yaml in the main branch as well? the chart-releaser tool already handles it for us by default?

@subigre you are right, chart-releaser action already updated index.yaml gh-pages branch but Github Pages is still pointing at master branch. I have updated Pages to point to gh-pages branch now. Hence no index.yaml and tar ball need to be updated into master branch. We will need to clean this up to avoid confusion.

FYI @DanielFran