XSF Editor Team - 2023-01-26

Right, no sign of the published XEPs. Anyone know how they're deployed? The docs say https://hub.docker.com/r/xmppxsf/xeps/builds/ but that seems to not be true.

indeed

you need to build that image locally and push it to some obscure registry hosted on gitlab.com

for which you probably don't have +w

Just found the repo in the create scripts, at least, ta.

Ok, I'll adapt that slightly, for the moment.

sorry for that, that's an artifact of the failed attempt to streamline stuff over at gitlab.com ✏

Not a problem, I just need to Do A Thing.

I don't see a lot of value in me fighting with a registry to upload a manual image when I could just upload directly to eos2, so I'm going to do that.

how would you upload to eos2 directly?

docker save ... | gzip | pv | ssh eos2 docker load

right

I never do that because it doesn't dedupliate the lower layer

which matters if you have 1 MB/s uplink :D

Maybe it's a stupid idea and I'm about to break everything. I guess we'll find out in a moment :) ✏

no, sounds about right

Alright, I now have a local script to do the build, upload and deploy.

Next step, I guess, working out if any cron or whatever on eos2 is going to overwrite it with the old version.

Oh, good, it looks like there's multiple things trying to serve xeps.

yes, there is a cronjob

I re-enabled it the other day

Worse, there's a cronjob that's serving xeps in a different manner.

uhuh?

did I mess that up?

(maybe iteam@?) ✏

I don't know.

(maybe move this to iteam@?) ✏

Right, looks like I'm now set up to publish XEPs and attic in one go.

woop woop

you probably won't continue my commit message history in the attic though

I did not.

I looked at it. I thought 'that's cute', and then continued to be lazy.

jonas’, Kev: should this eos2 instead run something like https://github.com/adnanh/webhook so merging an MR could tell it to pull and rebuild?

I'm entirely happy with doing the docker build locally, TBH.

It's one command I need to run to get it built and deployed.

Unless I'm missing something, the tooling once the PRs are ready to merge is pretty ok, it's all the stuff before that that's nuisanceful.

Next time I do a deploy I'll add a couple of extra lines to my local shell script, and everything'll be fine from that point of view.

All the checks when triaging is a nuisance.

> Next time I do a deploy I'll add a couple of extra lines to my local shell script, and everything'll be fine from that point of view. But only for you, not for any other or future editors

I'll share my script ;)

Plus all editors have to also be in iteam?

The deployment's automatic.

Anyway, I'm not saying we can't automate this bit further. Just that it's not the pain point.

Right others seem higher priority, just seems a bit like death by a thousand cuts

At least for me, the deployment now of xeps and attics is fairly painless (as long as I don't discover gremlins next time).But the bit where we interact with people on PRs is...not painless :)

If you want to review my triage.sh PR feel free :D

I've been mostly leaving MattJ for that, as he's got a better grip of where we're going with tooling, but I'll take a look, thanks.

moparisthebest, except for the missing approver thing, lgtm

jonas’: trying to fix that in that other MR, applying approver to all of them, then this can just be a hard error

Thanks for reviewing!

I haven't looked, but does this error because there are XEPs that don't have approver, or error if a *changed* XEP doesn't have approver?

I think the latter would be ok, it's a forcing function.

Hello, I'd just like to be sure https://xmpp.org/extensions/inbox/xep-sla.html doesn't fall between the chair shuffle of the new council and editor constellation. https://logs.xmpp.org/council/2023-01-04?p=h#2023-01-04-90f98d9660c9c364

Kev: it does different things based on whether the approver of the changed xep is council or board, and has an ugly "unknown" branch that should be deleted imho

But gotta make sure they all have them before that can be done