Stefan Bürk (b16e9d57) at 04 May 14:48
Stefan Bürk (b16e9d57) at 04 May 14:48
[TASK] Adjust core monorepo branch support
With TYPO3 v10 entering ELTS and thus ending community support, triggering CI runs are no longer needed. Ignore requests !
Additionally, requests for 12.1 are ignored and slack channel notification is shifted to send `main', '12.4' and '11.5' nightly result notification.
With TYPO3 v10 entering ELTS and thus ending community support, triggering CI runs are no longer needed. Ignore requests !
Additionally, requests for 12.1 are ignored and slack channel notification is shifted to send `main', '12.4' and '11.5' nightly result notification.
Stefan Bürk (b16e9d57) at 04 May 03:33
[TASK] Adjust core monorepo branch support
With TYPO3 v10 entering ELTS and thus ending community support, triggering CI runs are no longer needed. Ignore requests !
Additionally, requests for 12.1 are ignored and slack channel notification is shifted to send `main', '12.4' and '11.5' nightly result notification.
Stefan Bürk (0d4786ae) at 03 May 23:56
[TASK] Adjust core monorepo branch support
TYPO3 v10 entering ELTS in the nearer future, marking the end of official community support. Therefore, handling v10 branch(es) for pushing to Gitlab CI can be removed then.
After removing the v10 support from the Gerrit Adapter and
deployment has been executed, docker images can be removed
from testing-infrastructure
repository.
Stefan Bürk (1e3cea93) at 13 Sep 18:42
Stefan Bürk (1e3cea93) at 13 Sep 18:41
[BUGFIX] Don't create gitlab ci runs for merged security patches
Merging patches are done in the main repository. Each merge emits
a gerrit merge webhook request, which is used to send proper merge
message to the slack core dev channel, and also pushes the merged
commits to corresponding branches in main
and security
gitlab
repositories and to the gerrit internal repository for the security
project.
For security patches, which resides in the gerrit security project, gerrit adds the pushed merged commits to the corresponding changes as new patchset and marking them as merged. Gerrit does't distinguish between these merged pushes and normal change patchset pushes and thus emits a patch webhook event. This lead to creating patchset branches in the security gitlab repository and starting superflous pipeline runs, which had to be manually cancelled.
Gladly gerrit provides the uploader name, email and gerrit name of the account which created a change patchset. In case of the merged patch uploades this matches the security-ci account.
This change extends the GerritGitlabJob of the uploader and change
owner informations along with a isUploadedBySecurityCI
flag.
In case of security repository patch events from security-ci
as
uploader, this will be handled as merged push events and thus
gracefully skipped with a corresponding log entry.
Merging patches are done in the main repository. Each merge emits
a gerrit merge webhook request, which is used to send proper merge
message to the slack core dev channel, and also pushes the merged
commits to corresponding branches in main
and security
gitlab
repositories and to the gerrit internal repository for the security
project.
For security patches, which resides in the gerrit security project, gerrit adds the pushed merged commits to the corresponding changes as new patchset and marking them as merged. Gerrit does't distinguish between these merged pushes and normal change patchset pushes and thus emits a patch webhook event. This lead to creating patchset branches in the security gitlab repository and starting superflous pipeline runs, which had to be manually cancelled.
Gladly gerrit provides the uploader name, email and gerrit name of the account which created a change patchset. In case of the merged patch uploades this matches the security-ci account.
This change extends the GerritGitlabJob of the uploader and change
owner informations along with a isUploadedBySecurityCI
flag.
In case of security repository patch events from security-ci
as
uploader, this will be handled as merged push events and thus
gracefully skipped with a corresponding log entry.
Merging patches are done in the main repository. Each merge emits
a gerrit merge webhook request, which is used to send proper merge
message to the slack core dev channel, and also pushes the merged
commits to corresponding branches in main
and security
gitlab
repositories and to the gerrit internal repository for the security
project.
For security patches, which resides in the gerrit security project, gerrit adds the pushed merged commits to the corresponding changes as new patchset and marking them as merged. Gerrit does't distinguish between these merged pushes and normal change patchset pushes and thus emits a patch webhook event. This lead to creating patchset branches in the security gitlab repository and starting superflous pipeline runs, which had to be manually cancelled.
Gladly gerrit provides the uploader name, email and gerrit name of the account which created a change patchset. In case of the merged patch uploades this matches the security-ci account.
This change extends the GerritGitlabJob of the uploader and change
owner informations along with a isUploadedBySecurityCI
flag.
In case of security repository patch events from security-ci
as
uploader, this will be handled as merged push events and thus
gracefully skipped with a corresponding log entry.
Stefan Bürk (1e3cea93) at 13 Sep 16:45
[BUGFIX] Don't create gitlab ci runs for merged security patches
Stefan Bürk (62d3fa35) at 13 Sep 15:59
Stefan Bürk (62d3fa35) at 13 Sep 15:53
[TASK] Log merge/patch route request debug info
... and 1 more commit
Stefan Bürk (f9e042cd) at 17 Aug 17:09
[TASK] Mitigate problems private flag usages in gerrit
Stefan Bürk (51d5619a) at 14 Aug 16:47
[BUGFIX] Proper split superflous information from commit message
Stefan Bürk (4d191d92) at 18 Jul 23:31
[TASK] Simplify slack merged message
Stefan Bürk (b0cc1397) at 18 Jul 22:51
[TASK] Remove superflous gerrit query call and omit dates in merged...