1. 24 Jun, 2022 2 commits
    • Sjoerd Simons's avatar
      c201aa35
    • Ariel D'Alessandro's avatar
      aptly: Don't re-publish repositories on project updates · 7f373e09
      Ariel D'Alessandro authored
      
      
      Aptly is currently re-publishing (dropping and publishing again)
      repositories when the project configuration is changed. This is
      performed to update the components and architectures of the published
      distribution based on the updated project configuration.
      
      OBS/aptly contains a hack allowing the usage of slashes `/` in the
      publish distribution field, which we're currently using to have the
      snapshots published in the same prefix and using a distribution name
      with the form: `$release/snapshots/$timestamp`. This makes the snapshots
      folder to be inside the same `dists` directory where the repositories
      are published.
      
      There's a bug in the above implementation, where:
      * OBS project configuration is updated, triggering a re-publishing of
        the distribution.
      * Aptly drops the published distribution.
      * If aptly doesn't have any other distribution published in the same
        prefix, it will remove the entire `dists` folder, with all the
        snapshots in it.
      * Aptly publishes the distribution again.
      
      This bug is making aptly to drop all the snapshots, as it assumes these
      can't be stored within the published distribution.
      
      Let's HACK this quickly by disabling the re-publishing temporarily. Note
      that OBS will create the aptly repositories and publish them on the
      first project configuration, but it won't re-publish it at all on
      further config updates.
      
      Signed-off-by: Ariel D'Alessandro's avatarAriel D'Alessandro <ariel.dalessandro@collabora.com>
      7f373e09
  2. 23 Jun, 2022 1 commit
  3. 22 Jun, 2022 1 commit
  4. 17 Jun, 2022 3 commits
  5. 16 Jun, 2022 3 commits
  6. 15 Jun, 2022 1 commit
  7. 13 Jun, 2022 1 commit
  8. 10 Jun, 2022 1 commit
  9. 08 Jun, 2022 1 commit
  10. 27 May, 2022 2 commits
  11. 16 May, 2022 11 commits
  12. 12 May, 2022 6 commits
  13. 04 May, 2022 1 commit
    • Andrej Shadura's avatar
      Allow new SSO logins in "deny" mode · fca80a4d
      Andrej Shadura authored and Sjoerd Simons's avatar Sjoerd Simons committed
      
      
      The can_register check is actually only suitable for preventing new
      unverified registrations; in SSO mode, we normally trust the SSO
      provider have performed the checks and only gives us users we’re
      supposed to let in.
      
      Ideally, this should be a separate set of settings to allow e.g.
      optionally requiring confirmation on SSO logins or to configure
      different levels of trust per SSO provider.
      
      Signed-off-by: Andrej Shadura's avatarAndrej Shadura <andrew.shadura@collabora.co.uk>
      fca80a4d
  14. 03 May, 2022 1 commit
  15. 02 May, 2022 5 commits