XSF Editor Team - 2020-06-13


  1. bear has left
  2. winfried has left
  3. winfried has joined
  4. winfried has left
  5. winfried has joined
  6. winfried has left
  7. winfried has joined
  8. bear has joined
  9. winfried has left
  10. winfried has joined
  11. bear has left
  12. bear has joined
  13. winfried has left
  14. winfried has joined
  15. winfried has left
  16. winfried has joined
  17. winfried has left
  18. winfried has joined
  19. Tobi has joined
  20. winfried has left
  21. winfried has joined
  22. lnj has joined
  23. winfried has left
  24. winfried has joined
  25. winfried has left
  26. winfried has joined
  27. Guus has left
  28. Guus has joined
  29. jonas’ yo editors
  30. jonas’ you’d fancy an automated build which was incremental?
  31. winfried has left
  32. winfried has joined
  33. pep. Sure
  34. jonas’ so I figured that with gitlab CI pipelines, we can do all we ever wanted
  35. jonas’ we can get incremental builds and we have our own docker registry space which allows us to finally fix the XMPP registrar stuff
  36. winfried has left
  37. winfried has joined
  38. winfried has left
  39. winfried has joined
  40. jonas’ soo... by accident I also made a thing which provides a rendered HTML version for PRs
  41. jonas’ we should migrate to gitlab indeed
  42. pep. \o/
  43. jonas’ with the necessary tooling for incremental builds we also automatically gain the necessary tooling to render diffs in MRs
  44. jonas’ just sayin’
  45. jonas’ ahem
  46. jonas’ I’m having fun here
  47. jonas’ also, I have an automated registry build going
  48. jonas’ pep., you’re on board, right?
  49. jonas’ do I need board approval to make the gitlab.com/xsf group public and start doing things there?
  50. pep. yep
  51. pep. hmmm
  52. pep. I'd say that's iteam domain? Maybe some board members disagree
  53. jonas’ if that’s iteam domain, I say it’s ok ;-D
  54. pep. Well that can already be done in parallel anyway right?
  55. pep. Say as a transition we mirror the github repo
  56. Kev I'd say it needs Board's approval before people sign T&Cs on on behalf of the XSF, and Matt's approval before moving services.
  57. jonas’ Kev, ah, T&C is a good point
  58. pep. T&C?
  59. jonas’ terms & conditions
  60. pep. Ah terms
  61. jonas’ re gitlab use
  62. jonas’ so I’ll make that a board agenda item
  63. jonas’ and also confer with MattJ about ok-ness of using gitlab for stuff
  64. Kev 👍
  65. pep. Ok by asking board you just mean making the switch official, right?
  66. pep. You can already PR .gitlab-ci.yml stuff in github and mirror that today
  67. jonas’ pep., I’m not intending to switch anything, but using Gitlab resources is probably a thing Board needs to have talked about
  68. pep. Well atm gitlab.com/xsf is not representing the XSF :p
  69. jonas’ right, it’s kind of just an org I have happened to have created
  70. pep. yeah
  71. pep. So I'd say do whatever you want. The decision board needs to make would be to take in gitlab.com/xsf responsabilities
  72. pep. (or iteam*)
  73. jonas’ so my plan is now: - Sync with MattJ on the iteam topics - if MattJ greenlights, I’ll do the necessary flips and switches to move our image builds there this weekend, because we get a lot ouf of that - Then I’ll add a board item and let board decide if it’s ok to adobt gitlab.com/xsf as an XSF thing or if there’s a problem with that. - on the off-chance that board disagrees with the usage, we’ll roll back the experiment and start from square zero
  74. jonas’ pep., do you think people on Board could be unhappy with the kind of "fait accompli" way?
  75. pep. You mean like xmpp.work happened? :P
  76. jonas’ I take that as a "yes" ;P
  77. pep. Anyway if you need a pre-approval from board you have at least mine if that means anything
  78. jonas’ I’ll add a step after MattJ and before making switches which is testing the waters with board members
  79. pep. rules: - if: '$CI_COMMIT_REF_NAME =~ /^main$/' when: always - when: never
  80. pep. isn't there a different way to do this?
  81. pep. Something like `only: - main`
  82. jonas’ I copied this from stuff I did in the past. IIRC, there is a slight difference between only and rules
  83. jonas’ also this is more extensible
  84. pep. k
  85. jonas’ now thinking about attic integration
  86. pep. The "incremental" part is the cache right?
  87. jonas’ yes
  88. jonas’ and the ci-restore-timestamps.py script
  89. jonas’ otherwise all checked out files have $now as timestamp
  90. jonas’ which is generally newer than the cache
  91. pep. cache and artifacts have different timeout values?
  92. jonas’ -> make rebuilds all the things
  93. jonas’ cache is a singleton, artifact is per job instance
  94. jonas’ cache has indefinite lifetime AFAIK
  95. jonas’ cache is reloaded across pipeline instances, artifacts are not
  96. pep. Right. Even though that can also be configured
  97. jonas’ not out of the box I think
  98. jonas’ artifacts can only be loaded across jobs (via dependencies or stages; this is used in pack@main in xeps and registrar), but not across pipelines. Unless you put a token and an explicit URL to the artifact somewhere
  99. pep. Right I meant cache. Artifacts indeed are a per-job thing
  100. pep. hmm, as I guess that'll be in the pack of questions, isn't it possible to cache stuff with travis already?
  101. jonas’ is not relevant, since we cannot build docker images from travis
  102. jonas’ or at least we have no place to push them to
  103. pep. can't push that to docker hub at all?
  104. jonas’ if you give it credentials it might
  105. jonas’ but then there’s the question about dockerhub itself which has questionable permissions requirements for the github integration
  106. pep. ok
  107. winfried has left
  108. winfried has joined
  109. Tobi has left
  110. Tobi has joined
  111. lnj has left
  112. winfried has left
  113. winfried has joined
  114. Tobi has left
  115. winfried has left
  116. winfried has joined
  117. winfried has left
  118. winfried has joined