you’d fancy an automated build which was incremental?
winfriedhas left
winfriedhas joined
pep.
Sure
jonas’
so I figured that with gitlab CI pipelines, we can do all we ever wanted
jonas’
we can get incremental builds and we have our own docker registry space which allows us to finally fix the XMPP registrar stuff
winfriedhas left
winfriedhas joined
winfriedhas left
winfriedhas joined
jonas’
soo... by accident I also made a thing which provides a rendered HTML version for PRs
jonas’
we should migrate to gitlab indeed
pep.
\o/
jonas’
with the necessary tooling for incremental builds we also automatically gain the necessary tooling to render diffs in MRs
jonas’
just sayin’
jonas’
ahem
jonas’
I’m having fun here
jonas’
also, I have an automated registry build going
jonas’
pep., you’re on board, right?
jonas’
do I need board approval to make the gitlab.com/xsf group public and start doing things there?
pep.
yep
pep.
hmmm
pep.
I'd say that's iteam domain? Maybe some board members disagree
jonas’
if that’s iteam domain, I say it’s ok ;-D
pep.
Well that can already be done in parallel anyway right?
pep.
Say as a transition we mirror the github repo
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.
jonas’
Kev, ah, T&C is a good point
pep.
T&C?
jonas’
terms & conditions
pep.
Ah terms
jonas’
re gitlab use
jonas’
so I’ll make that a board agenda item
jonas’
and also confer with MattJ about ok-ness of using gitlab for stuff
Kev
👍
pep.
Ok by asking board you just mean making the switch official, right?
pep.
You can already PR .gitlab-ci.yml stuff in github and mirror that today
jonas’
pep., I’m not intending to switch anything, but using Gitlab resources is probably a thing Board needs to have talked about
pep.
Well atm gitlab.com/xsf is not representing the XSF :p
jonas’
right, it’s kind of just an org I have happened to have created
pep.
yeah
pep.
So I'd say do whatever you want. The decision board needs to make would be to take in gitlab.com/xsf responsabilities
pep.
(or iteam*)
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
jonas’
pep., do you think people on Board could be unhappy with the kind of "fait accompli" way?
pep.
You mean like xmpp.work happened? :P
jonas’
I take that as a "yes" ;P
pep.
Anyway if you need a pre-approval from board you have at least mine if that means anything
jonas’
I’ll add a step after MattJ and before making switches which is testing the waters with board members
I copied this from stuff I did in the past. IIRC, there is a slight difference between only and rules
jonas’
also this is more extensible
pep.
k
jonas’
now thinking about attic integration
pep.
The "incremental" part is the cache right?
jonas’
yes
jonas’
and the ci-restore-timestamps.py script
jonas’
otherwise all checked out files have $now as timestamp
jonas’
which is generally newer than the cache
pep.
cache and artifacts have different timeout values?
jonas’
-> make rebuilds all the things
jonas’
cache is a singleton, artifact is per job instance
jonas’
cache has indefinite lifetime AFAIK
jonas’
cache is reloaded across pipeline instances, artifacts are not
pep.
Right. Even though that can also be configured
jonas’
not out of the box I think
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
pep.
Right I meant cache. Artifacts indeed are a per-job thing
pep.
hmm, as I guess that'll be in the pack of questions, isn't it possible to cache stuff with travis already?
jonas’
is not relevant, since we cannot build docker images from travis
jonas’
or at least we have no place to push them to
pep.
can't push that to docker hub at all?
jonas’
if you give it credentials it might
jonas’
but then there’s the question about dockerhub itself which has questionable permissions requirements for the github integration