Hi, I've been a professional developer and DevOps engineer for 18 years 🤓. I share original content from diverse real-world production experiences through monthly blog posts.
That’s not really instant type checking though. gitlab-ci-local validates YAML after it’s written and run through a separate tool. AFAIK it doesn’t prevent you from writing invalid configs in the first place.
It’s also a fairly large, non-official dependency that we’d need to enforce across the team. In our case, we already work exclusively in TypeScript in a complex NX monorepo, so this is just native TS tooling doing what it already does best.
2. extends, includes, anchors
We used all of those extensively before. They help, but they’re still string-based and fairly fragile: typo a job name, forget to include a file, or misunderstand merge behavior and things silently stop working.
Importing files and composing objects in TypeScript proved more simple for us.
3. IDE extensions / DX without abstraction
Interesting. I wasn't aware of a widely used IDE extension for GitLab CI that gives the same level of refactoring and safety. Which one? I have GitLab workflow installed in vscode and for .gitlab-ci.yml files specifically it only helps with hinting the YAML field names.
Anyways, I feel like enforcing a specific IDE plugin across the team is still not the most ideal approach. With TypeScript, autocomplete, refactoring, docs, and error checking are already there. No extra tooling or setup beyond what we already use every day.
Conclusion
Just to be clear, the goal of this article isn't to say "GitLab YAML bad". This different approach just fits our project and team better. We’re already very TS-minded, and once pipelines reach a certain size and complexity, treating them as code instead of configuration has proven easier to reason about and maintain for us.
I'll try to update the article so it's a little more nuanced.
Hi, I've been a professional developer and DevOps engineer for 18 years 🤓. I share original content from diverse real-world production experiences through monthly blog posts.
Thanks. Indeed you would gain depth in it by addressing inner reader questions like those.
i've never been around a project with development abstraction layer on GitLab for my past 7 years actively doing GitLab consulting, But I'd like to see that in action whenever I get the chance. But for now, nothing convince me of doing it for myself (on projects I get to choose).
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I love uncharted territories on GitLab, thank you for sharing ! You should add #gitlab tag, it has better traction that some of the ones you defined.
For now i do not really understand the advantages f your workflow...
gitlab-ci-local can also do it, without any abstraction layer.
extends, references and includes can also do it without any abstraction layer.
IDE extension and gitlab-ci-local can also do that without any abstraction layer
Thank you for the reply. I appreciate your input!
Let me clarify how this fits my workflow:
1. "Type safety" via
gitlab-ci-localThat’s not really instant type checking though.
gitlab-ci-localvalidates YAML after it’s written and run through a separate tool. AFAIK it doesn’t prevent you from writing invalid configs in the first place.It’s also a fairly large, non-official dependency that we’d need to enforce across the team. In our case, we already work exclusively in TypeScript in a complex NX monorepo, so this is just native TS tooling doing what it already does best.
2.
extends,includes, anchorsWe used all of those extensively before. They help, but they’re still string-based and fairly fragile: typo a job name, forget to include a file, or misunderstand merge behavior and things silently stop working.
Importing files and composing objects in TypeScript proved more simple for us.
3. IDE extensions / DX without abstraction
Interesting. I wasn't aware of a widely used IDE extension for GitLab CI that gives the same level of refactoring and safety. Which one? I have
GitLab workflowinstalled in vscode and for.gitlab-ci.ymlfiles specifically it only helps with hinting the YAML field names.Anyways, I feel like enforcing a specific IDE plugin across the team is still not the most ideal approach. With TypeScript, autocomplete, refactoring, docs, and error checking are already there. No extra tooling or setup beyond what we already use every day.
Conclusion
Just to be clear, the goal of this article isn't to say "GitLab YAML bad". This different approach just fits our project and team better. We’re already very TS-minded, and once pipelines reach a certain size and complexity, treating them as code instead of configuration has proven easier to reason about and maintain for us.
I'll try to update the article so it's a little more nuanced.
Thanks. Indeed you would gain depth in it by addressing inner reader questions like those.
i've never been around a project with development abstraction layer on GitLab for my past 7 years actively doing GitLab consulting, But I'd like to see that in action whenever I get the chance. But for now, nothing convince me of doing it for myself (on projects I get to choose).