Mesa CI Optimization Could Provide Big Bandwidth Savings

[pal666]

What bothers me, why is this change to the mesa repository?

because gitlab ci scripts are contained in repo

[pal666]

btw, i have experience with gitlab ci and it sucks

[pal666]

This makes me wonder how long it'll be until clouds become cost prohibitive and if we'll start seeing companies and projects go back to self-hosting. 70K covers a lot of hardware & electricity costs.

self-hosting requires paying salary for personnel, so $70k per year is not that much. i.e. it can make sense for large users with predictable workloads

[pal666]

If they can afford the risk of getting up to 70k in CI costs, they could afford to pay someone for much less to assist if they lacked the proper domain experience, rather than expect voluntary contributions.

who are "they"? everything mesa does is done by voluntary contributions

[pal666]

You explicitly don't want to cache the repository. You want your build agent to be a clean environment each time in order to ensure reproducible builds.

you've got it backwards. build environment is checked-out worktree, which they don't cache. what they cache is git history. (and btw history caching is cornerstone of git architecture).

If you use a modern SCM you can use web hooks to notify jenkins of events.

if you use gitlab, you use gitlab ci instead of jenkins

The most sensible solution is to send web hook notifications for merges into the master/release branches and when a pull request is opened (or an open pull request is modified). That will massivily reduce bandwidth costs.

giltab ci knows when pull request is opened or modified, it just was doing rm -rf on local git tree followed by clone(you should be proud of them - they didn't cache anything just as you suggested)