Currently job artifacts in CI/CD pipelines on LRZ GitLab never expire. Starting from Wed 26.1.2022 the default expiration time will be 30 days (GitLab default). Currently existing artifacts in already completed jobs will not be affected by the change. The latest artifacts for all jobs in the latest successful pipelines will be kept. More information: https://gitlab.lrz.de/help/user/admin_area/settings/continuous_integration.html#default-artifacts-expiration

  1. 21 Jul, 2015 1 commit
  2. 20 Jul, 2015 1 commit
  3. 05 May, 2014 1 commit
  4. 13 Dec, 2013 1 commit
  5. 10 Nov, 2013 1 commit
    • Artur Grunau's avatar
      MdiDockableWindow: override the activateWindow method · a00b0215
      Artur Grunau authored
      The default implementation of activateWindow didn't forward activation
      requests to MdiDockableWindow's sub-windows. Since MdiDockableWindow is
      always hidden, the method was pretty much a no-op in disguise.
      
      The overridden version of activateWindow properly forwards activation
      requests, using the right method to activate the current sub-window, no
      matter if it's floating or docked.
      a00b0215
  6. 02 Nov, 2013 1 commit
    • Artur Grunau's avatar
      MdiDockableWindow: new MDI helper class · 6d4262de
      Artur Grunau authored
      MdiDockableWindow has been extracted from MdiDockArea to simplify and
      better structure our MDI implementation. The new class takes care of
      creating all necessary representations (docked and floating window) of
      widgets added to MdiDockArea and seamlessly switching between them in
      response to the user's actions (window dragging, key presses, etc).
      
      MdiDockableWindow improves our MDI implementation in two ways:
      - MdiFloatingWindow and MdiDockedWindow instances shouldn't be
        interacted with directly; they're created and disposed of as needed,
        and therefore can't be used as a handle to access and modify an MDI
        window's state; MdiDockableWindow, in contrast, fits this role
        perfectly; it manages both representations of an MDI window, and as
        a result stays around as long as at least one of them is needed
      - managing state transitions of many sub-windows directly in MdiDockArea
        was becoming clumsy as signal mapping and dynamic properties were
        required; having a separate widget that only has to control the state
        of one sub-window makes the code related to state transitions much
        simpler
      6d4262de