Skip to content
Snippets Groups Projects
  1. Jun 30, 2021
  2. Jun 28, 2021
  3. Jun 24, 2021
  4. Jun 17, 2021
  5. Jun 15, 2021
  6. Jun 10, 2021
  7. Jun 09, 2021
  8. Jun 08, 2021
    • Simon McVittie's avatar
      mtree: Parse the ignore, nochange and optional flags · 16e20ba0
      Simon McVittie authored
      
      The nochange flag is fully implemented here: it suppresses changing the
      modification time or permissions.
      
      The optional flag is mostly implemented here: it suppresses the error
      that would ordinarily occur if a file with content does not already
      exist.
      
      The ignore flag is not yet implemented, only parsed, because it only
      really applies when verifying whether a filesystem tree matches a
      specification.
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      16e20ba0
    • Simon McVittie's avatar
      mtree: Parse modification times in a compatible way · c1cba1a3
      Simon McVittie authored
      
      time=1.234 has historically meant 1 second + 234 nanoseconds, or what
      normal people would write as 1.000000234. Parse it as such, but for now
      treat this ambiguous format as an error, unless the fractional part is
      exactly ".0" which is unambiguous - we can relax this to a warning
      later, if we want to.
      
      libarchive and FreeBSD mtree show mtimes with exactly 9 decimal digits,
      which makes them mean the same thing in either interpretation.
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      c1cba1a3
    • Simon McVittie's avatar
      mtree: Accept content= as a synonym for contents= · 7b9568a6
      Simon McVittie authored
      
      libarchive allows both, although FreeBSD and NetBSD mtree do not.
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      7b9568a6
    • Simon McVittie's avatar
      Don't automatically run CI for pushes to master · 9f720fb8
      Simon McVittie authored
      
      When we push to master it's usually for one of three reasons:
      
      1. We merged a merge request
      2. We pushed the "release vX.Y.Z" commit, together with a tag
      3. We pushed some other trivial change directly
      
      When we merged a merge request, immediately running CI is not
      necessarily very helpful, because we already ran it for the branch
      that's getting merged.
      
      If we pushed a release commit and a tag, we want the CI pipeline for
      the tag to take priority over the CI pipeline for the release commit.
      
      If we pushed a trivial change, it might not even need CI (if it's just
      a change to a README, or similar), but if it does, we can trigger it
      manually.
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      9f720fb8
    • Simon McVittie's avatar
      CI: Don't run pipelines for merge requests · fdf69aac
      Simon McVittie authored
      
      If we avoid running pipelines for merge requests, then the status of the
      pipeline for the branch will show up. The pipeline for the branch can be
      more comprehensive because it has access to project-specific masked and
      protected variables.
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      fdf69aac
Loading