1. 29 Nov, 2021 4 commits
  2. 26 Nov, 2021 2 commits
    • Michael Hofmann's avatar
      Merge: Be more verbose when killing container processes · 118e5521
      Michael Hofmann authored
      
      
      There seems to be a race condition when terminating processes.
      
      As an example, the following processes are normally running for the
      kernel subsystems webhook:
      
      ```text
      USER         PID  STAT TIME COMMAND
      cki            1  Ss   0:00 /bin/bash /usr/local/bin/cki_entrypoint.sh
      cki           10  S    0:00 /bin/bash /usr/local/bin/cki_entrypoint.sh
      cki           11  S    0:00 /bin/bash /usr/local/bin/cki_entrypoint.sh
      cki           12  S    0:00 tee -a /logs/subsystems-kernel-webhooks-subsystems
      cki           14  Sl   0:22 python3 -m webhook.subsystems
      cki           15  S    0:00 python3 -m webhook.utils.update_git_mirror
      cki           16  S    0:00 python3 -m webhook.utils.update_kernel_watch
      cki           17  S    0:00 python3 -m webhook.utils.update_owners
      ```
      
      A failing subsystems hook resulted in the following processes running:
      
      ```text
      USER         PID  STAT TIME COMMAND
      cki            1  Ss   0:00 /bin/bash /usr/local/bin/cki_ent
      cki           10  S    0:00 /bin/bash /usr/local/bin/cki_ent
      cki           12  S    0:00 tee -a /logs/subsystems-kernel-webhooks-subsystems
      cki           15  S    0:01 python3 -m webhook.utils.update_git_mirror
      cki           16  S    0:00 python3 -m webhook.utils.update_kernel_watch
      cki           17  S    0:01 python3 -m webhook.utils.update_owners
      ```
      
      PID 11 seems to correspond to the main function. This condition can be
      reproduced inside the container by first killing process 11, which
      prevents the kill commands at the end of the main function from running,
      and then killing process 14.
      
      So one theory is that the kill -- -$$ in the main function kills itself,
      preventing the other processes from being killed. In that condition, the
      container will stay up until either (1) the tee or (2) all Python
      processes are killed.
      
      As a workaround, implement option (2) by storing all spawned processes
      in an array and killing them one-by-one.
      Signed-off-by: Michael Hofmann's avatarMichael Hofmann <mhofmann@redhat.com>
      
      See merge request !337
      118e5521
    • Michael Hofmann's avatar
      Be more verbose when killing container processes · f6f25be0
      Michael Hofmann authored
      
      
      There seems to be a race condition when terminating processes.
      
      As an example, the following processes are normally running for the
      kernel subsystems webhook:
      
      ```text
      USER         PID  STAT TIME COMMAND
      cki            1  Ss   0:00 /bin/bash /usr/local/bin/cki_entrypoint.sh
      cki           10  S    0:00 /bin/bash /usr/local/bin/cki_entrypoint.sh
      cki           11  S    0:00 /bin/bash /usr/local/bin/cki_entrypoint.sh
      cki           12  S    0:00 tee -a /logs/subsystems-kernel-webhooks-subsystems
      cki           14  Sl   0:22 python3 -m webhook.subsystems
      cki           15  S    0:00 python3 -m webhook.utils.update_git_mirror
      cki           16  S    0:00 python3 -m webhook.utils.update_kernel_watch
      cki           17  S    0:00 python3 -m webhook.utils.update_owners
      ```
      
      A failing subsystems hook resulted in the following processes running:
      
      ```text
      USER         PID  STAT TIME COMMAND
      cki            1  Ss   0:00 /bin/bash /usr/local/bin/cki_ent
      cki           10  S    0:00 /bin/bash /usr/local/bin/cki_ent
      cki           12  S    0:00 tee -a /logs/subsystems-kernel-webhooks-subsystems
      cki           15  S    0:01 python3 -m webhook.utils.update_git_mirror
      cki           16  S    0:00 python3 -m webhook.utils.update_kernel_watch
      cki           17  S    0:01 python3 -m webhook.utils.update_owners
      ```
      
      PID 11 seems to correspond to the main function. This condition can be
      reproduced inside the container by first killing process 11, which
      prevents the kill commands at the end of the main function from running,
      and then killing process 14.
      
      So one theory is that the kill -- -$$ in the main function kills itself,
      preventing the other processes from being killed. In that condition, the
      container will stay up until either (1) the tee or (2) all Python
      processes are killed.
      
      As a workaround, implement option (2) by storing all spawned processes
      in an array and killing them one-by-one.
      Signed-off-by: Michael Hofmann's avatarMichael Hofmann <mhofmann@redhat.com>
      f6f25be0
  3. 23 Nov, 2021 2 commits
    • Michael Hofmann's avatar
      Merge: Redeploy everything if a pipeline was triggered manually · 90cb69f0
      Michael Hofmann authored
      
      
      At the moment, deployments to production in branch pipelines only happen
      if the configured paths changed.
      
      Improve that so that if a pipeline is triggered manually in the web
      interface via the "Run pipeline" button, all deployments happen.
      Somebody triggering a branch pipeline from there most likely does not
      care about the specific files changed in the HEAD commit, but wants to
      run a full pipeline including all deployments.
      Signed-off-by: Michael Hofmann's avatarMichael Hofmann <mhofmann@redhat.com>
      
      See merge request !334
      90cb69f0
    • Michael Hofmann's avatar
      Redeploy everything if a pipeline was triggered manually · 3899bd81
      Michael Hofmann authored
      
      
      At the moment, deployments to production in branch pipelines only happen
      if the configured paths changed.
      
      Improve that so that if a pipeline is triggered manually in the web
      interface via the "Run pipeline" button, all deployments happen.
      Somebody triggering a branch pipeline from there most likely does not
      care about the specific files changed in the HEAD commit, but wants to
      run a full pipeline including all deployments.
      Signed-off-by: Michael Hofmann's avatarMichael Hofmann <mhofmann@redhat.com>
      3899bd81
  4. 16 Nov, 2021 2 commits
  5. 15 Nov, 2021 3 commits
  6. 05 Nov, 2021 1 commit
  7. 04 Nov, 2021 2 commits
  8. 03 Nov, 2021 3 commits
  9. 29 Oct, 2021 1 commit
  10. 28 Oct, 2021 1 commit
  11. 27 Oct, 2021 2 commits
  12. 26 Oct, 2021 4 commits
  13. 20 Oct, 2021 2 commits
  14. 19 Oct, 2021 2 commits
  15. 18 Oct, 2021 3 commits
  16. 14 Oct, 2021 2 commits
  17. 13 Oct, 2021 2 commits
  18. 04 Oct, 2021 2 commits