This blog post was originally published on the GitLab Unfiltered blog. It was reviewed and republished on 2020-08-04.
The people who work at GitLab are encouraged to build the things they want and need, which helps us expand the ways we work with our growing product. We're thrilled to announce that we've created an official GitLab Workflow Extension for VS Code.
How did we get here?
More than two years ago, Fatih Acet, a former senior frontend engineer, Plan, started working on a VS Code extension to allow users to interact with GitLab from within their code editor. At GitLab, everything starts with a Merge Request, which is exactly how Fatih started building the extension. Fatih, along with more than 25 contributors, continued to expand on the extension by adding new features. The extension has been installed more than 160,000 times.
It’s been remarkable to see the way the community collaborated to build the extension, making it a tool that is valuable to their work. The GitLab Workflow Extension is the perfect case study of how developers can create meaningful work at this company.
When Fatih decided to move on from GitLab in March 2020, we had an opportunity to take over the GitLab Workflow Extension, turning it into a tool GitLab would officially maintain and support. We jumped at the opportunity to maintain an auxilary project outside of the main GitLab project. As we continue to move fast and create the best experiences possible for our users, we expect this extension to become a key component of our strategy.
How to use the extension
If you want to start using the extension, you can install it from within VS Code directly by searching for GitLab Workflow which is now published through an official GitLab account.
If you were already using the extension, it automatically updated to the GitLab publisher, and you might have already seen a few updates coming in.
What improvements have we made?
When we took over the extension, we worked with other teams across GitLab to immediately perform an application security review. Along the way, we made sure to create a security release-process. We did this to ensure that users were safe to continue using the extension and so that we could fix any problems that surface. We also worked through some automation to help with publishing the extension and begin to lay a foundation for future testing.
We also shipped version 3.0.0 which was spearheaded by our community and helped to resolve some long-standing bugs and issues. The extension has come a long way in just a few short weeks. We’re excited by the progress we’re making and the engagement we’re continuing to see, but there is still a lot that needs to be done.
What’s next?
Nothing in software development is perfect, and so we are aware of the shortcomings of the extension, some inconsistencies, and some long open feature requests. You can see our many to-dos on our GitLab Workflow Extension issues list. For now, we’re focused on triaging the existing issues and capturing any new bugs. You should see much more involvement from our Create:Editor team as we continue these efforts, and we’re looking forward to engaging with the community on these items.
We’re also evaluating the best path forward for maintaining the extension, by focusing on the test-suite and code-quality, so we won’t break things by accident. You can join us in our discussion on this issue. While this might slow down some new feature releases in the short-term, we’re confident these are the right long-term decisions to ensure you have an extension you can trust, so you can make the GitLab Extension an integral part of your workflow.
Everyone can contribute
The extension is open source, and we're improving the "How to Contribute" guides alongside some other documentation. We want to have a space where everyone can contribute and make this extension better for all of us.
Check out more engineering content on GitLab
- How to build containers with the AWS Fargate Custom Executor for GitLab Runner and AWS CodeBuild
- How application security engineers can use GitLab to secure their projects
- Best practices to keep your Kubernetes runners moving
