1. 18 Jun, 2022 1 commit
  2. 31 Mar, 2022 1 commit
  3. 12 Feb, 2022 1 commit
  4. 29 Jan, 2022 1 commit
    • Stefan Bürk's avatar
      [TASK] Revamp phpstan config and handling · 997722b8
      Stefan Bürk authored and Christian Kuhn's avatar Christian Kuhn committed
      We currently have the situation that phpstan is
      hard to update and maintain due to the phpstan
      config file that sets very specific rulesets.
      This is unfortunate since phpstan tends to change
      and rename rules at will.
      The general usage API of phpstan is basically as
      follows: Have a slim config file that sets the
      basic level. Then maintain a 'baseline' file that
      lists violations, using the --generate-baseline
      command option. The todo job for people working
      on phpstan errors is then to look at the baseline
      file, pick up some issues, fix them, then re-generate
      baseline. When baseline is small enough, the level
      is raised, a new baseline is generated, and the
      fix-job starts again.
      The patch does exactly this: The existing config
      is dropped and runTests.sh receives a command to
      generate baseline.
      With this in place, we can easily raise phpstan
      to a PHP 8.1 compatible version:
      > composer req friendsoftypo3/phpstan-typo3:"^0.9.0" --dev
      > composer req phpstan/phpstan:"^1.4.3" --dev
      > Build/Script/runTests.sh -s phpstanGenerateBaseline
      This initialy adds about 4000 ignores to the baseline
      with level 3, but we can reduce this drastically with
      just a couple of dedicated patches, soon.
      The config is heavily streamlined and for instance does
      *not* ignore tests anymore, which actually finds a ton
      of misuses and bugs within tests and classes.
      Resolves: #96675
      Releases: main, 11.5
      Change-Id: I0e7ff7aa796e59a2c5eedde0b673f741f8b87dea
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/73037
      Tested-by: core-ci's avatarcore-ci <typo3@b13.com>
      Tested-by: Daniel Goerz's avatarDaniel Goerz <daniel.goerz@posteo.de>
      Tested-by: Stefan Bürk's avatarStefan Bürk <stefan@buerk.tech>
      Tested-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      Reviewed-by: Stefan Bürk's avatarStefan Bürk <stefan@buerk.tech>
      Reviewed-by: Daniel Goerz's avatarDaniel Goerz <daniel.goerz@posteo.de>
      Reviewed-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
  5. 18 Jan, 2022 1 commit
  6. 30 Nov, 2021 1 commit
    • Christian Kuhn's avatar
      [TASK] gitlab-ci: Out-of-order nightly jobs · 070ab15e
      Christian Kuhn authored
      Usually, when running jobs in gitlab-ci, they're
      organized in stages - jobs of a second stage only
      execute when all jobs of the previous stage were
      The pre-merge jobs use this to supress jobs in case
      the "early" stage checking cgl and composer
      fail. This helps suppressing waste of resources.
      The nightly jobs are organized in more logical stages.
      The stage supression isn't too useful here. Pipelines
      are only executed as scheduled pipelines or manually
      to sometimes test if the extended nightly jobs are
      happy with a single patch before merging it.
      To reduce runtime of nightlies, they now introduce
      a gitlab-ci feature for single stage jobs that ignore
      stage boundaries. With this out-of-order configuration
      the stage separation is basically ignored, which on one
      side reduces overall runtime of nightlies since more
      jobs are executed in parallel and on the other side now
      find all issues in case multiple merged patched kill a
      nigthly and one hides fails from the other away due to
      stage constraints.
      Change-Id: I8e461592eecd0a66b0fcf6ee5ab14509ebec8277
      Resolves: #96166
      Releases: master, 11.5
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/72409
      Tested-by: core-ci's avatarcore-ci <typo3@b13.com>
      Tested-by: Stefan Bürk's avatarStefan Bürk <stefan@buerk.tech>
      Tested-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      Reviewed-by: Stefan Bürk's avatarStefan Bürk <stefan@buerk.tech>
      Reviewed-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
  7. 29 Nov, 2021 1 commit
  8. 17 Oct, 2021 2 commits
  9. 12 Sep, 2021 1 commit
  10. 11 Sep, 2021 1 commit
  11. 13 Aug, 2021 2 commits
  12. 06 Aug, 2021 1 commit
  13. 20 Apr, 2021 1 commit
  14. 24 Mar, 2021 1 commit
  15. 11 Mar, 2021 1 commit
  16. 28 Feb, 2021 1 commit
  17. 08 Feb, 2021 1 commit
  18. 04 Feb, 2021 1 commit
  19. 03 Feb, 2021 1 commit