1. 22 Sep, 2020 3 commits
  2. 08 Sep, 2020 1 commit
  3. 07 Sep, 2020 1 commit
  4. 05 Sep, 2020 3 commits
  5. 25 Aug, 2020 1 commit
    • anonym's avatar
      Release process: use sudo in a less error prone manner. · 77ff48c8
      anonym authored
      If sudo times out between IUKs, which happens occasionally, it is very
      easy to miss the sudo password prompt since this scripts outputs a lot
      of stuff. So let's just run the whole script with sudo to eliminate
      this risk.
      77ff48c8
  6. 24 Aug, 2020 1 commit
  7. 21 Aug, 2020 1 commit
  8. 18 Aug, 2020 1 commit
  9. 16 Aug, 2020 1 commit
    • intrigeri's avatar
      SquashFS sort file: ignore cpufreq and net kernel modules · 632472aa
      intrigeri authored
      These drivers, when loaded during the "SquashFS file order" part of the release
      process, reflect the hardware being used at the time, which:
      
       - won't match the broad range of hardware our users use
       - unnecessarily leaks information about the RM's hardware
      
      So let's not include them in the SquashFS sort file.
      632472aa
  10. 29 Jul, 2020 1 commit
  11. 28 Jul, 2020 4 commits
  12. 03 Jul, 2020 2 commits
  13. 02 Jul, 2020 2 commits
  14. 30 Jun, 2020 3 commits
  15. 10 Jun, 2020 1 commit
  16. 08 Jun, 2020 1 commit
  17. 06 Jun, 2020 2 commits
    • intrigeri's avatar
      Automate post-release GitLab updates, using gitlab-triage (#17589) · 9e11debf
      intrigeri authored
      We will use gitlab-triage to solve other problems soon
      (https://salsa.debian.org/tails-team/gitlab-migration/-/issues/54),
      and it's the perfect tool for the job, so it makes sense
      to start using it here as well.
      
      Since gitlab-triage is not in Debian, in order to be compliant with the security
      policies applicable to Release Managers:
      
       - run gitlab-triage in Docker
       - ensure we always use the latest version of gitlab-triage,
         in a fresh Docker image based on the latest version of debian:stable
      9e11debf
    • intrigeri's avatar
      Release process: switch to a dedicated role user for GitLab automation · e566904c
      intrigeri authored
      For now that's mostly a no-op.
      
      Once we use this role user to postpone issues & MRs, this will:
      
       - avoid release managers getting subscribed to notifications
         of every postponed issue;
      
       - avoid the need for release managers' personal GitLab account
         to have access to every confidential issue in every project;
      
       - remove one blocker for migrating such GitLab automation
         to our infrastructure, so that RMs don't need the ability
         to impersonate the role-release-automation user anymore.
      e566904c
  18. 03 Jun, 2020 5 commits
  19. 02 Jun, 2020 6 commits