However more and more development features get locked into vendor specific implementations, like testing and building using Gitlab CI/CD or Github Actions, security evaluation (eg: dependabot) and issue management workflows that required bots and the Github API. It's easy enough to host your code on a mirror, even a static http would suffice if needed, but getting your release out the door reliably is getting harder.
Imo that's overstated. Sure, there's always some vendor-specific configuration needed, but that should be dwarfed by the vendor-neutral setup, after all you also need something to run tests locally.
Bug reports and support requests are handled using Github, mainly because that’s what is widely used in the industry right now, but bugs actually fixed are usually described in Git commits, where the information can easily be mirrored.
This is not a major problem if you push to all mirrors. E.g. if you're using Bitbucket CI, but also mirror your git repo in github, gitlab (as GP did) then you can just push to everyone and that will automatically trigger bitbucket CI, as well github CI (if you want to switch in the future). Of course, you'll have to maintain each CI manifest separately.
> Of course, you'll have to maintain each CI manifest separately.
Not just the manifest, the way your entire project interacts with the CI ecosystem. Which in an ideal world would be no problem, but in practice comes down to a lot of implementation specific details per environment.
12 comments
[ 2.8 ms ] story [ 14.8 ms ] threadImo that's overstated. Sure, there's always some vendor-specific configuration needed, but that should be dwarfed by the vendor-neutral setup, after all you also need something to run tests locally.
You'd think so but for many projects contributors rely entirely on the CI system.
Testing is done in a Docker container, so the CI/CD pipeline is available in a Dockerfile and the scripts the Dockerfile imports in to the testing container. In my case: https://github.com/samboy/MaraDNS/tree/master/Docker-stuff
Bug reports and support requests are handled using Github, mainly because that’s what is widely used in the industry right now, but bugs actually fixed are usually described in Git commits, where the information can easily be mirrored.
Not just the manifest, the way your entire project interacts with the CI ecosystem. Which in an ideal world would be no problem, but in practice comes down to a lot of implementation specific details per environment.