1. 21 Mar, 2020 1 commit
    • Nicolás Alvarez's avatar
      staticweb: don't copy timestamps in rsync · 2af08db8
      Nicolás Alvarez authored
      Turns out the previous commit didn't fully work; it seems rsync doesn't
      copy content because the content matches (--checksum), but still syncs the
      file timestamp (--times, implied by --archive), so files still get touched
      on every deploy and If-Modified-Since requests remain ineffective.
      If I *don't* sync the mtime, files that actually get transferred will
      still have the mtime changed, but to the time rsync wrote them on the
      server rather than the local file's mtime. Files that don't get transferred
      will stay as they are.
      I could keep using -a (--archive) and explicitly disable copying
      timestamps (--no-times). However, -a implies -rlptgoD, and most of those
      are actually pointless for us (we can't copy ownership, we have no device
      nodes, sockets or fifos). Instead, replace -a with -rlp (recursive,
      symlinks, permissions), which is all we need. The lack of -t should fix
      the timestamp-touching issue.
  2. 17 Mar, 2020 1 commit
    • Nicolás Alvarez's avatar
      staticweb: avoid transferring unchanged files to the webserver · 8977fad0
      Nicolás Alvarez authored
      Since we're building websites from scratch on clean environments, even
      cloning the git repository every time, every file will have a recent
      modification timestamp. This means rsync will copy every file to the
      webserver even if it didn't actually change. Also, clients making
      conditional requests with If-Modified-Since will get the whole file
      rather than 304 Not Modified.
      For example, any tiny typo fix in kde.org will touch every page and image
      in it, and the hackergotchi images in planet.kde.org will have their
      modtime touched every hour.
      This commit adds -c / --checksum to the rsync command. It makes rsync
      calculate the hash of the local and remote file, and transfer it only if
      it actually changed, rather than only comparing size and modtime. That way
      if a file didn't change in the source git repository, or if the generation
      process created an file identical to the previous version, it will not be
      updated during deployment.
  3. 29 Sep, 2019 1 commit
  4. 27 Sep, 2019 1 commit
  5. 24 Aug, 2019 1 commit
  6. 06 Aug, 2019 1 commit
  7. 05 Aug, 2019 1 commit
  8. 04 Aug, 2019 1 commit
  9. 22 Sep, 2018 1 commit
  10. 24 Aug, 2018 1 commit
  11. 25 May, 2018 5 commits
  12. 22 May, 2018 4 commits
  13. 21 May, 2018 2 commits