Skip to content

GitLab

Switch branch/tag
  1. 21 Jan, 2022 1 commit
  3. 22 Oct, 2021 1 commit
  5. 07 Sep, 2021 1 commit
  7. 29 Jul, 2021 1 commit
  9. 27 Jan, 2021 1 commit
  11. 21 Jan, 2021 1 commit
  13. 23 Dec, 2020 1 commit
  15. 17 Nov, 2020 2 commits
  17. 29 Oct, 2020 1 commit
    • Nirbheek Chauhan's avatar
      gitlab: Fix cannot overwrite directory error when symlinking · b0f5da22
      Nirbheek Chauhan authored 
      GitLab doesn't wipe images entirely before reusing them across jobs.
It relies on the build scripts to not write outside the workdir.
However, we create symlinks outside of the workdir, which breaks in
weird ways.

Specifically, when ../../gstreamer/cerbero exists, `ln -sf` creates
../../gstreamer/cerbero/cerbero, which is wrong, but doesn't cause an
error. However, when the image is reused again after this,
../../gstreamer/cerbero/cerbero already exists, so `ln -sf` yields:

ln: ../../gstreamer/cerbero/cerbero: cannot overwrite directory

This is fixed in master after overhauling the scripts to never write
outside of workdir, but for 1.16 we need to hack it by not symlinking
if the target dir already exists.

Originally commited to the 1.16 branch in
!370

The proper fix will be backported from master, but let's fix this
error in the meantime so it doesn't roadblock the 1.18 stable releases

Part-of: <!374>
      b0f5da22
  19. 27 Oct, 2020 1 commit
    • Jordan Petridіs's avatar
      citemplate: remove fdo.expires-after label · 5421bfe6
      Jordan Petridіs authored 
      This is meant to be used for containers that are going
to be periodically rebuilt. For our usecase specifying
`fdo.upstream-repo` is enough to garbage collect all
the tags from the forks.

We also need to rebuild the images, so they don't have
include the label anymore.

Part-of: <!373>
      5421bfe6
  21. 22 Oct, 2020 1 commit
    • Jordan Petridіs's avatar
      citemplate: tweak merge-request rules · 1ba7dd97
      Jordan Petridіs authored and Tim-Philipp Müller's avatar Tim-Philipp Müller committed 
      With the MergeRequest rules template, its was impossible
to manually create or trigger a pipeline for a branch/commit
that was not part of a merge request.

This tweaks the workflow:rules such that there will always be
a pipeline for each commit (which will be set to a manual job trigger).

There is the downside that we will now be triggering 2 pipelines in
case of merge requests, but they will require manual action to be
started.

Part-of: <!371>
      1ba7dd97
  23. 14 Oct, 2020 1 commit
  25. 28 Sep, 2020 1 commit
  27. 15 Sep, 2020 1 commit
  29. 14 Sep, 2020 2 commits
  31. 09 Sep, 2020 3 commits
  33. 27 Aug, 2020 2 commits
  35. 05 Aug, 2020 1 commit
  37. 04 Aug, 2020 1 commit
  39. 26 Jul, 2020 2 commits
  41. 24 Jul, 2020 1 commit
  43. 23 Jul, 2020 2 commits
  45. 10 Jul, 2020 1 commit
  47. 09 Jul, 2020 1 commit
  49. 03 Jul, 2020 8 commits
  51. 02 Jul, 2020 1 commit