nakedgremlin
Joined 15 years ago
Joined 15 years ago
> A free Tess subscription to use their own model for brainstorming and scaling repetitive work (roughly 1 in 4 artists took advantage of this)
So based on the math I'm seeing... the 21 artists in the system, only 5 ("1 in 4") optioned to use the tool for their own productivity? That seems really low and makes me wonder what the user experience for creation feels like. I would assume if you decided to commit to this endeavor, you would want to see what derivative results will look like.
It's so sad that we can't just run local validations on the CI/CD script through a local emulator. If they had a local emulator approach similar to what is provided by Firebase for their cloud products, that would be amazing.
I'd love to know more on the business-front for deals like this. Is that a yearly cost? What's the typical expectation for support for something like this?
This definitely isn't my realm of experience at all, so I don't even know if this is a big deal or not. The fact they noted the "bragging rights" makes this feel like a low cost.
Now being part of the same owner, just makes it feel like any aggressive progress will just stall out.
The current interface provided for removing the artifacts on GitLab just does not work. There is no feedback; no confirmation. We just uncheck a box and just cross our fingers since there is no other step noted.
Even with the new guidance provided, it's still additional jumps through other codebases just to see if it works. I'm now worried that if I go through this new process, I'll end up right back at the same issue.
The artifacts storage is that one that's just tough to figure out when dealing with large builds. We have already offloaded all our CI/CD to our own hosted GitLab runners, but apparently storing the artifacts afterwards (which by default GitLab always stores the most recent builds) MUST use their storage, we can't offload it to our own servers.
The instructions for removing the most recent artifacts also just never works (https://docs.gitlab.com/ee/ci/pipelines/job_artifacts.html#k...)
So in our monorepo with multiple Windows and Mac applications, we are now stuck with lots of GB that are just there, currently unable to delete.
This is causing us to dramatically revisit our strategy of using GitLab and might force us to other tools.
The nice thing with this type of separation for us is being able to target CI/CD scripts to specific apps. Previously we were using targeted dev script logic to initiate the different app builds which just wasn't maintainable. This new approach this time around made for Electron deployments to be super simple, consistent, and repeatable.
All this was done by two team members on dev side.