When testing mobile apps, how do you manage the data at the backend? i.e how do you ensure that data that you see in the app is he same every time and actions during the test do not affect the data for the next test?
When testing the backend in frameworks such as Rails, this is taken care of by seed data and DB transactions.
> i feel like you have never touched servers/backend in anything more than simple projects (or at all). with full storage/memory there could be an issue that you won't be able to ssh to the server, so it speaks about your knowledge in this matter.
He was answering that.
If instead of dismissing someone outright and question their competence, you had
raised specific concerns, this would have been a more productive conversation
> You question his competence.
> He was answering that.
> If instead of dismissing someone outright and question their competence, you had raised specific concerns, this would have been a more productive conversation
he first said that we don't need to monitor anything, just enable debugging when "business metrics" are failing, and then he changed his stance to "polling from time to time". that's just shows that his first take wasn't thoughtful, so I assumed that he never worked in "the field" or worked on smaller projects, as nobody that worked in bigger projects would say that "we don't need CPU/mem/hdd metrics". it's not like hes proposing something novel, that just ridiculous take that needs to be called out
At the moment, I think you'd want to use both products together, i.e. using `depot build` in place of `docker build` to move the container build portion to a Depot container builder.
I'd like to have a more automatic integration at some point - the challenge is that a lot of BuildKit's architecture performs best when many different build requests all arrive at a single build host, it is then able to efficiently deduplicate and cache work across all those build requests. So you really want the many different Actions jobs all communicating with the same BuildKit host.
We have some ideas for reducing the amount of change to Actions workflows to adopt ^ - longer term we're also working on our own build engine, to free those workloads from being confined to single hosts (be that single CI runners or single container builders).
This is pretty much exactly what I wanted (yay for custom images) but the pricing makes it a non starter. Please consider a tiered monthly pricing based on build minutes.
I don't understand what makes the pricing a non starter. You mean the license pricing? If so, 300€/year for something that will save you thousands doesn't seem too expensive to me. If you're talking about the instances, it is 10x cheaper than comparable GitHub runners (i.e. same as ubicloud), so not sure what's wrong here :)
reply