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