What support task(s) would make it possible to [regularly] deploy dev branch to production

[patcon]

@colinmegill @pol-is/core I understand that there's a disjunct between the codebase as it existed before (separate repos) and the codebase today (monorepo), where the ease of the old deploy process doesn't seem to have translated well to the new codebase. But I don't really have an understanding of what would allow us to be be deploying updates to hosted Pol.is more quickly.

Even at the pace of like 1 deploy/month, that might be nice.

(I don't think there's been a new push to production since the monorepo split in the spring, correct?)

I've seen a few people wander away because certain bugs were still present. Having outstanding bugs is totally understandable (given other big priorities of org), but there could perhaps be more understanding of timeline and barriers. Right now, the returning call participants are just kinda reassuring people on calls that "Yes, feature X (mainly: facebook login, data exports) has been broken for a year, and we're not clear on the timeline to fix, but we promise this project is exciting and isn't going away"

Is there any chance you can share anything about the bottlenecks (in capacity? in tooling? in understanding? in confidence?) that prevent us from deploying more regularly?

And is there any way that others could support you in removing these bottlenecks? (I've been working on tests, thinking that will provide more confidence in the underlying changes, but I'm not clear if this is addressing the crux of the issue 😃 )

cc: @ballPointPenguin @pol-is/community

[micahstubbs]

+1 for removing bottlenecks.

As a new person and potential contributor, the 60+ GB disk space requirement to run docker image is a point of friction that I experienced.

[patcon]

Thanks micah :) Off top of head...

Potential spin-out task:

• merge client-admin + client-report (one less container)
• makefile targets for easier cleanup, minimal builds (pulling instead of building some parts), etc.
• realign diverged docker image versions (gulp update required for full sync)
• docker perf improvements
• improve local dev experience (without docker)

PS, NOT saying we should create tickets for all these, just ideating on actions in case anyone wants to +1 and escalate any toward that

[micahstubbs]

I'd like to explore the idea of fewer frontend sub-projects. I think that this would simplify development, if it doesn't interference with the current usage and deployment storing for the Admin UI and the Reporting UI.

[dvagala]

+1
We wanted use polis in my home country, but now we're stuck, because my Slovak translation isn't getting to the production :(