XSF Editor Team - 2020-06-13

yo editors

you’d fancy an automated build which was incremental?

Sure

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

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

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

we should migrate to gitlab indeed

\o/

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

just sayin’

ahem

I’m having fun here

also, I have an automated registry build going

pep., you’re on board, right?

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

yep

hmmm

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

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

Well that can already be done in parallel anyway right?

Say as a transition we mirror the github repo

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.

Kev, ah, T&C is a good point

T&C?

terms & conditions

Ah terms

re gitlab use

so I’ll make that a board agenda item

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

👍

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

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

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

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

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

yeah

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

(or iteam*)

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

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

You mean like xmpp.work happened? :P

I take that as a "yes" ;P

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

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

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

isn't there a different way to do this?

Something like `only: - main`

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

also this is more extensible

k

now thinking about attic integration

The "incremental" part is the cache right?

yes

and the ci-restore-timestamps.py script

otherwise all checked out files have $now as timestamp

which is generally newer than the cache

cache and artifacts have different timeout values?

-> make rebuilds all the things

cache is a singleton, artifact is per job instance

cache has indefinite lifetime AFAIK

cache is reloaded across pipeline instances, artifacts are not

Right. Even though that can also be configured

not out of the box I think

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

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

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

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

or at least we have no place to push them to

can't push that to docker hub at all?

if you give it credentials it might

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

ok