actions/fluxcd-flux2
3
0
Fork 0
mirror of https://github.com/fluxcd/flux2.git synced 2026-02-22 15:41:47 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 2

Correct sentence

Browse source 
Signed-off-by: Somtochi Onyekwere <somtochionyekwere@gmail.com>
This commit is contained in:
Somtochi Onyekwere 2022-04-16 18:00:50 +01:00
parent bd50aa2d6d
commit 99765b1f5a
1 changed files with 1 additions and 1 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2
rfcs/0008-commitstatus/README.md
View file

@ -16,7 +16,7 @@ There should be a dedicated kind in the notification controller for sending comm
Currently, The Alert type can reference both git providers and chat providers. However, the differences between the two providers and how notifications being sent to them should be handled has continued to diverge. Currently, The Alert type can reference both git providers and chat providers. However, the differences between the two providers and how notifications being sent to them should be handled has continued to diverge.
For example, there is a limit on the length of the name/context of the status for git provider. For example, there is a limit on the length of the name/context of the status for git provider.
When one commit triggers more than one deployment, the commit status notification from one overwrites the other as seen in this [issue](https://github.com/fluxcd/notification-controller/issues/195). When one commit triggers more than one deployment/reconciliation in different clusters, the commit status notification from one overwrites the other as seen in this [issue](https://github.com/fluxcd/notification-controller/issues/195).
A new field specific to the git commit status will allow Flux users to specify a prefix that will be prepended to the context to differentiate the statuses. A new field specific to the git commit status will allow Flux users to specify a prefix that will be prepended to the context to differentiate the statuses.
By creating a separate kind for git commit status, the specific nuances of the provider can be properly taken into account and it would allow more flexibility in adding fields specific to each kind. By creating a separate kind for git commit status, the specific nuances of the provider can be properly taken into account and it would allow more flexibility in adding fields specific to each kind.