XSF Editor Team - 2020-06-13

  1. jonas’

    yo editors

  2. jonas’

    you’d fancy an automated build which was incremental?

  3. pep.


  4. jonas’

    so I figured that with gitlab CI pipelines, we can do all we ever wanted

  5. jonas’

    we can get incremental builds and we have our own docker registry space which allows us to finally fix the XMPP registrar stuff

  6. jonas’

    soo... by accident I also made a thing which provides a rendered HTML version for PRs

  7. jonas’

    we should migrate to gitlab indeed

  8. pep.


  9. jonas’

    with the necessary tooling for incremental builds we also automatically gain the necessary tooling to render diffs in MRs

  10. jonas’

    just sayin’

  11. jonas’


  12. jonas’

    I’m having fun here

  13. jonas’

    also, I have an automated registry build going

  14. jonas’

    pep., you’re on board, right?

  15. jonas’

    do I need board approval to make the gitlab.com/xsf group public and start doing things there?

  16. pep.


  17. pep.


  18. pep.

    I'd say that's iteam domain? Maybe some board members disagree

  19. jonas’

    if that’s iteam domain, I say it’s ok ;-D

  20. pep.

    Well that can already be done in parallel anyway right?

  21. pep.

    Say as a transition we mirror the github repo

  22. 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.

  23. jonas’

    Kev, ah, T&C is a good point

  24. pep.


  25. jonas’

    terms & conditions

  26. pep.

    Ah terms

  27. jonas’

    re gitlab use

  28. jonas’

    so I’ll make that a board agenda item

  29. jonas’

    and also confer with MattJ about ok-ness of using gitlab for stuff

  30. Kev


  31. pep.

    Ok by asking board you just mean making the switch official, right?

  32. pep.

    You can already PR .gitlab-ci.yml stuff in github and mirror that today

  33. jonas’

    pep., I’m not intending to switch anything, but using Gitlab resources is probably a thing Board needs to have talked about

  34. pep.

    Well atm gitlab.com/xsf is not representing the XSF :p

  35. jonas’

    right, it’s kind of just an org I have happened to have created

  36. pep.


  37. pep.

    So I'd say do whatever you want. The decision board needs to make would be to take in gitlab.com/xsf responsabilities

  38. pep.

    (or iteam*)

  39. 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

  40. jonas’

    pep., do you think people on Board could be unhappy with the kind of "fait accompli" way?

  41. pep.

    You mean like xmpp.work happened? :P

  42. jonas’

    I take that as a "yes" ;P

  43. pep.

    Anyway if you need a pre-approval from board you have at least mine if that means anything

  44. jonas’

    I’ll add a step after MattJ and before making switches which is testing the waters with board members

  45. pep.

    rules: - if: '$CI_COMMIT_REF_NAME =~ /^main$/' when: always - when: never

  46. pep.

    isn't there a different way to do this?

  47. pep.

    Something like `only: - main`

  48. jonas’

    I copied this from stuff I did in the past. IIRC, there is a slight difference between only and rules

  49. jonas’

    also this is more extensible

  50. pep.


  51. jonas’

    now thinking about attic integration

  52. pep.

    The "incremental" part is the cache right?

  53. jonas’


  54. jonas’

    and the ci-restore-timestamps.py script

  55. jonas’

    otherwise all checked out files have $now as timestamp

  56. jonas’

    which is generally newer than the cache

  57. pep.

    cache and artifacts have different timeout values?

  58. jonas’

    -> make rebuilds all the things

  59. jonas’

    cache is a singleton, artifact is per job instance

  60. jonas’

    cache has indefinite lifetime AFAIK

  61. jonas’

    cache is reloaded across pipeline instances, artifacts are not

  62. pep.

    Right. Even though that can also be configured

  63. jonas’

    not out of the box I think

  64. 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

  65. pep.

    Right I meant cache. Artifacts indeed are a per-job thing

  66. pep.

    hmm, as I guess that'll be in the pack of questions, isn't it possible to cache stuff with travis already?

  67. jonas’

    is not relevant, since we cannot build docker images from travis

  68. jonas’

    or at least we have no place to push them to

  69. pep.

    can't push that to docker hub at all?

  70. jonas’

    if you give it credentials it might

  71. jonas’

    but then there’s the question about dockerhub itself which has questionable permissions requirements for the github integration

  72. pep.