GitLab Incubation Engineering, 28 Oct 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Incubation Engineering Jamstack -- Weekly Demo October 28th 2021

Description

MR: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/73183

CI/CD templates experience Issue by Nadia: https://gitlab.com/gitlab-org/gitlab/-/issues/335376

Jamstack Weekly Updates: https://gitlab.com/gitlab-org/incubation-engineering/jamstack/meta/-/issues/5

A

Hi, I'm janis welcome to the weekly update for the drumstack incubation engineering scg at github, I'm currently working on a gitlab pages. Onboarding page.

A

You know I had spent some time on a source, editor extension dealing with yaml files, the last couple of weeks.

A

That extension is now in review, and I am back trying to iterate over the page that I had actually written it, for um this is how the onboarding page looked like last time that we talked about it.

A

The problem that I had with this site is the fact that the gitlab ci yaml file requires a lot of information in order for the pipeline to work. It needs a build image: the installation, script, the build script, the destination folder, the branch and ideally also a cache instruction.

A

If I would put all this info into input fields on the left hand side, this would feel absolutely overwhelming uh similar to editing the yaml directly. So I guess the benefit of the whole onboarding page would be gone to solve this. We could either make a few educated assumptions like the build image is almost always going to be no latest or the cache folder will very very likely be node modules.

A

But what if it is not? I mean we support non-js frameworks like hugo, making these kind of assumptions putting them into the yammer without asking that suggests like we don't. So I think this wouldn't be the best idea. I mean we could make automated guesses based on the files in the project intelligently, identifying next based on a next config js, for example, and this is definitely something that I would like to look at in the future. I know this idea is a constant in the incubation engineering department, but in the spirit of iteration.

A

I really wanted to go with a much simpler idea for now, so I'm still asking the user to give me all the information, but I made the process a bit better. um So what I did is I broke down this form into multiple steps now flowing from one step to another, and now I can get all the input I need and still not overwhelm the user.

A

Some pages only have a single input field, giving this hey. This is easy feeling and, as a second effect, I can build up the contents of the yaml file step by step. That makes it so much less intimidating.

A

I mean I can still even highlight hey. This is the exact point of the change you're making right now, um but I also make the surrounding structure a bit more bite-sized.

A

So the last step again is to commit this newly created yarn file.

A

I have created this draft, mr for this change. I'll, put the link in the video description now I still need to resolve a few issues with this. Mr, for example, the navigation is based on a view router, which makes it very elegant, but it can lose its state during a page reload. So that's a finicky thing that I still need to address. There's a few other minor things, so the next update will probably be rather boring me resolving all these issues.

A

I do want to very quickly address how this page fits in the general pipeline authoring thing that just try to solve this very similar issue, meaning making building a yaml file more friendly.

A

So, ideally, what I'm doing here is something that can be done in the pipeline authoring section at some stage too, but I think since pages doesn't have onboarding at the moment. It's a great area where we can experiment with this in a very limited scope, we don't need to cater for all project types, we're generic enough to cater for most static sites, but not so generic that we're just replicating the entire gitlab ci yaml documentation, just as input fields.

A

um One idea that I had could be that we can create an individual onboarding path like this for all common project types like we're, not just offering templates but the whole guided input.

A

Building on this fantastic suggestion from nadia, you select a project type like in this design, and then you get redirected to an onboarding program like the one I made for static sites, instead of hundreds of yama templates for every firm framework out there. We could just have a couple of different onboarding routes depending on the project type know it's just an idea um and I'll leave it at that for today.

A

But thank you so much for your attention. I'll see you next week.