You could potentially use a regularly scheduled pipeline in GitLab CI to do this. You'd need to use a user token instead of the pipeline token since you want to push back into the repository, but this should be possible. Then, when GitLab CI updates the repo, Netlify CI should jump in.
One relatively easy way to debug is to set up a runner instance on your machine and then send jobs that you're working on there. In that way you are validating real jobs, but can also monitor and interact with what's happening in real time.
We have a new PM for the runner and this is on his agenda to research and improve. The reality is that the job execution environment is complex - each job does just have a simple script section which is just shell commands, but there is a lot of context that impacts behavior (to which environment are you deploying, what environment variables are set specific to that environment, is it a protected environment with variables that are shareable to any random user, are artifacts being passed, and so on.) Making iterating on pipelines easier is definitely on our agenda, and adding your thoughts to issues like https://gitlab.com/gitlab-org/gitlab-runner /issues/2226 or making new ones for your specific use case will help. We are also working on other oblique solutions to make pipelines easier to iterate on like https://gitlab.com/gitlab-org/gitlab/issues/39527, which help solve the problem in a different way where you don't need to try to replicate the state of the world on your local environment but can still find and fix problems quickly.
EDIT: I should also mention, https://gitlab.com/groups/gitlab-org/-/epics/2072 is a big priority for us where we want to reduce the time to first green pipeline (not just for new users, but for new projects too). Feedback is welcome there as well.
We are looking to add breakpoints in an upcoming release, building on our interactive web terminals feature. If you're interested in providing feedback the public issue is https://gitlab.com/gitlab-org/gitlab/issues/39527.
Thanks, that's really great to hear. Release evidence, and where we plan to take that feature long term (https://about.gitlab.com/direction/release/release_governanc...) is really exciting to me, having spent a lot of my career in release management. Would be great to get your feedback on where we are headed - even if you aren't a GitLab user today, may you will be in the future.
Interesting list, thanks for sharing. I'm the PM for CI/CD at GitLab, and I don't mean to hijack the topic, but wanted to give a heads up that we are looking at building a feature for these kinds of procedures that aren't quite pipelines, based on Jupyter Runbooks. Would love to hear your feedback: https://gitlab.com/gitlab-org/gitlab/issues/9427
Currently the most difficult and most time consuming step in the release checklist is finding space on my desk for three laptops so I can use them all simultaneously. Releasing only takes 1-3 hours, and I unfortunately wouldn't want to spend hours learning and setting up automated methods to perhaps shave 10 minutes off the process.
Manual releasing allows me to iteratively improve the process and spot possible issues, whereas any automation would reduce build reliability.
> whereas any automation would reduce build reliability.
I guess this depends on what your release process is; for example, most npm libraries benefit from CI that runs the build script and runs `npm version $TAG && npm publish`. There's not much that could be improved here, especially if the build script is just an alias for running `webpack`.
Hey, CI/CD PM here. I'd love to learn more about how you're using GitLab for mobile, if you're up for it ping me at @jlenny on gitlab.com. It's an area of focus for us, and it's always great to get to know another person who is using that use case.
We use it with Fastlane to automate our entire build and delivery pipeline. We set it up for our mobile clients, too, and it saves us a lot of time getting code shipped quickly.
We have a Mojave VM configured with Xcode, Fastlane, and the gitlab runner.
We automate uploads to Appetize.io for every feature branch so that QA and clients can test out new features in a simulator running in the browser.
We automate builds and uploads to Apple test flight and Google playstore alpha tracks on our develop branch.
The gitlab runner is by far the most reliable and easiest to setup part of the whole deal with the worst being maybe cocoapods or npm for the projects that rely on them (react-native).
I'll ping you on gitlab. Happy to go into more detail!
We've recently run into an issue with building react-native on Gitlab-CI, where apparently the build process spins up a file watcher in the background which quickly exhausts the open file descriptors.
Have you experienced anything like this? We are using stock react-native and not customizing anything.
Haven't had this issue, no. Are you running into the same problem if you build the app without the runner? The file watcher (do you mean metro?) shouldn't be running during a production build since the files aren't changing, right?
PM for CI/CD here, thanks so much for your feedback! As much as I'm excited about how much you love the product, we can always do better and I'd love to hear your thoughts. Ping me any time (@jlenny) on any issues that are important to you that would make things better.
