Run CI/CD pipelines on a schedule Improving UI FE and UX

This issue will need minor edits, I will be available as UX'r, beep me up in the channel or here

added me as resource at the top of this issue

@markpundsack @joshlambert see #next-iterations-could-include section for how we could iterate on this further ;)

changed title from Run CI/CD pipelines on a schedule Improving UI and UX to Run CI/CD pipelines on a schedule Improving UI FE and UX

@hazelyang (what do you think about the illustration?)

@dimitrieh Looks good!

Only have a thought: It looks a little bit heavy at first sight. I think possibly it's because of the shape(the red arrow points to) with a solid background. Perhaps we could try to make it only with the border? 🙂

This is really awesome. I guess "Last Pipeline" needs backend work. Need to calculate from TriggerRequest.

Anyway, maybe we can improve builds index page, as well?

Currently, it's marked as triggered. This is same with external trigger(API call). At least, it should be marked as scheduled or something like that?

mentioned in issue #30892 (closed)

assigned to @brycepj

From ~Frontend @brycepj will be working on that. From backend @zj will be helping.

@dosuken123 I think we need to differentiate between API triggers and scheduling in the UI.

Api triggers: Triggered
Scheduled triggers: Scheduled

would that make sense to you?

@hazelyang improved the drawing as you suggested, see description

edit: updated issue description with this info

mentioned in issue #30675 (moved)

mentioned in merge request !10473 (closed)

@dimitrieh Awesome stuff!

I'm confused by the content after Every Day, Week, Month. I don't think it's obvious what those times mean, nor is it necessary. Or at least not phrased that way. How about Every Day (at 4:05pm), Every Week (On Sunday at X:XXam), etc. Talk about when it will run, not how long from now it will run. Current time is kinda irrelevant.

Let's avoid the word "schedulement". "Schedule not set yet" would work better.

I still think it would be better to have the nightly, weekly, monthly buttons create cron for them, so they have something to edit. I can click on the examples and see how cron format changes, to learn the format. Also, daily really should focus on nightly since it's far more common that people want the job to run after work has finished, not mid-day, for example.

What timezone is this all in? Previous mockups let the user pick the timezone. Now it's ambiguous. Working in GMT is not easy for most people.

Search and conditions should not be a priority. We may never need them. I don't believe Multiple scheduled pipelines is a priority either.

Variables are a priority, so let's get them in soon.

One-off schedule jobs are a nice to have. Not urgent, but have a good use-case.

@dimitrieh This is fantastic ⭐ I have a bunch of questions, mostly clarifying details or making sure I'm clear on prioritization for the first iteration.

What will happen when the user clicks Cron syntax?
I think it's a bit confusing to see the calendar icon in the interval pattern field (to me, that means datepicker), when we only expect a cron interval. WDYT?
Should we validate the cron interval input on the frontend, or let the backend sort it out?
Is pagination of scheduled pipelines a priority for the first iteration?
Jobs / pipeline list tags should but updated as well -- that just means we need to display the Triggered/Scheduled label? Or is there more here that needs to change?
Is it correct that nothing here is changing about the Triggers UI?
Adding a trigger currently doesn't provide the branch selector dropdown. It just accepts text input of a branch name. Is the dropdown selector important for the first iteration?
Is the Take Ownership button a part of the first iteration?

cc: @ayufan @zj @markpundsack

Should we validate the cron interval input on the frontend, or let the backend sort it out?

I think both? Backend has to do it either way, but maybe the frontend could check it with a simple regex or so? The pattern is about /\A((\*(\/\d{1,2})?|\d{1,2})\s{,1}){5}\z/

assigned to @dimitrieh

From a contributor insight,

Should we validate the cron interval input on the frontend, or let the backend sort it out?

This validation is tricky, so if you also want to do that in FE, probably you need to find an appropriate library. Currently, BE is using an external library(gem) rufus-scheduler as validater and parser. So that at least we need to check the source code and if that's compatible with js side. Regex could be workaround, but since we have to cover wide cases http://www.nncron.ru/help/EN/working/cron-format.htm and https://en.wikipedia.org/wiki/List_of_tz_database_time_zones, figuring out the fine regex may be cumbersome (e.g. 59 23 31 DEC Fri, etc).

Jobs / pipeline list tags should but updated as well -- that just means we need to display the Triggered/Scheduled label? Or is there more here that needs to change?

Triggered label has already been shown for "external trigger"(triggered via API) and "scheduled trigger"(triggered via sidekiq-cron). This is because both triggers consist of TriggerRequest. But since considering "scheduled trigger" as "trigger" is little strange by user perspective, that should be renamed as "scheduling pipeline"(As declared in this proposal) and the label also should be refactored as well.

Adding a trigger currently doesn't provide the branch selector dropdown. It just accepts text input of a branch name. Is the dropdown selector important for the first iteration?

This was supposed to be in the first iteration (please see https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/10533#note_27060527), however, we didn't have much time to finish so removed it. The feature should be implemented in 2nd iteration.

Is the Take Ownership button a part of the first iteration?

This has already existed in app/views/projects/triggers/_trigger.html.haml. I guess you just need to copy the relevant codes. This is not a new feature.

Accepting cron syntax implies to cover it fully if possible. For example, the regexp given by @zj does not seems to cover the interval expressions, e.g.: 0 8-18 * * 1-5 which means "run it every hours from 8H to 18H and from monday to friday". Or the "list" syntax, e.g.: 0 9,13,15 * * * which means "run it at 9H, 13H, 15H".

These syntaxes are really usefull to schedule builds only during working hours, which helps reducing load by avoiding unnecessary builds.

I really would like to have the stable hash functionality, u.e. use H for minutes and hours so daily builds can be evenly distributed over 24 hours to have a more constant workload on shared runners.

And as I assume this page will not be visited.repeatedly during the day, I think backend validation is OK, Jenkins does it like this as well.

@mfriedenhagen Jenkins Hash mechanism is awesome. This should be considered at some point. How about creating a new issue for that? This issue seems to only focus on frontend change (thus targetted %9.2). Hash mechanism doesn't seem to be feasible, so that it's hard to finish in next version, I guess.

mentioned in issue #31008 (moved)

Created #31008 (moved) for Hash mechanism

mentioned in issue #31016 (closed)

mentioned in issue #31017 (closed)

I'm confused by the content after Every Day, Week, Month. I don't think it's obvious what those times mean, nor is it necessary. Or at least not phrased that way. How about Every Day (at 4:05pm), Every Week (On Sunday at X:XXam), etc. Talk about when it will run, not how long from now it will run. Current time is kinda irrelevant.

@markpundsack this was originally what @ayufan asked. But we can change that if you want. The thing what this avoided is, the inclusion of having to specify a timezone.

Also, daily really should focus on nightly since it's far more common that people want the job to run after work has finished, not mid-day, for example.

Thats the point ;) for some people its at night other day.. I assumed gmt or utc +00 or something. But let's iterate on this with a new design!

buttons create cron for them, so they have something to edit. I can click on the examples and see how cron format changes, to learn the format.

Yes i think this is nice. The radio buttons will be/stay selected if their exact cron definition is inputted. As when clicking on a/different radio button it will replace the current input with the preset.

Variables are a priority, so let's get them in soon.

Will get that in, this mockup

One-off schedule jobs are a nice to have

we will do that in a sep issue https://gitlab.com/gitlab-org/gitlab-ce/issues/30675

What will happen when the user clicks Cron syntax?

@brycepj I will try to answer the questions that i can ;)

It will open up a new tab with gitlab cron documentation

I think it's a bit confusing to see the calendar icon in the interval pattern field (to me, that means datepicker), when we only expect a cron interval. WDYT?

Seems good logic, will adjust! This was mostly for the similar functionality and looks as the revamped issue search and filtering. But as we are simplifying to just cron we don't need it actually.

Is pagination of scheduled pipelines a priority for the first iteration?

Yes, as we don't want the same performance trap/situation that we had with the environments page (as it became unusable... loading times for 2min+ resulting in outrageously bad UX)

we need to display the Triggered/Scheduled label?

correct!

Is it correct that nothing here is changing about the Triggers UI?

The triggers UI will go back to what it already was, without the basic scheduling functionality that it now has.

Adding a trigger currently doesn't provide the branch selector dropdown. It just accepts text input of a branch name. Is the dropdown selector important for the first iteration?

This is up to you. I consider it bad UX to not offer this.. while we already have this functionality in other places (so should be simple to add right?)... if we not have this, it makes it far less approachable/easy.

Is the Take Ownership button a part of the first iteration?

This is a remnant of the triggers... i wouldn't consider it super important.. as long as masters can delete any schedule. (cc: @markpundsack what do you think?)

New design

If agreed, i will update the description ;) and unassign!

oh will incorporate the variables still of course! which will basically look like an extra section of this:

@dimitrieh I think scheduled jobs have the same ownership challenges that triggers have, so take ownership is still important here. If someone on your team is leaving, you need to transfer ownership to someone remaining.

@markpundsack I think we should remove an owner. If someone can add it, why does he need to own it? No other setting is owned this way. Environments, as example, shouldn't have an owner IMO?

@zj They need to own it because pipelines trigged on the schedule need to run as somebody to inherit project authorizations for submodules, registry images, etc.

Right, good catch.

@markpundsack alright let's leave that in then!

updating issue description and unassigning

removed assignee

@axil there is question on cron documentation in the issue description ;)

@brycepj @zj this should be ready for implementation. Let me know when I missed details and I will be ready to get to you! I will be off and on next week.. (See availability calendar) if so please ask someone from the UX team 😺

Why is Select a timezone such a big field?

Thoughts on words:

Name tab "Schedule".
Title of dismissible help: "Pipelines Schedule" (Maybe "Pipeline Schedule")
Content of dismissible help: "The Pipelines Schedule runs pipelines in the future, either once or repeatedly, for specific branches or tags." (Specifically, drop "force") (Unless we don't ship one-time, then drop that clause) "Those scheduled pipelines will inherit limited project access based on their associated user." ("Impersonate" is too strong here. We should fix the documentation as well, and really clarify what exactly this means. e.g. Pipelines can't write to non-current projects, only read.)
Button label: "New schedule" (Technically, New Schedule Entry, but that's kinda lame. Maybe New schedule pipeline is fine, but a bit long.)

Column should be "Next run".

It feels like the timezone should be after selecting the schedule, especially given the title of the section.

"interval pattern" is still bugging me, but not sure what to say instead.

"interval pattern" is still bugging me, but not sure what to say instead.

@markpundsack What about Timing or Frequency?

I want to just say "Schedule", but that's overloading the word since the whole thing is a schedule. Might still be accurate though. One problem with Frequency is that we plan on offering one-time schedule pipelines, in which case Frequency doesn't fit.

Why is Select a timezone such a big field?

I took the notation from http://stackoverflow.com/questions/1727077/generating-a-drop-down-list-of-timezones-with-php in which there are some pretty long timezone descriptions/titles. we could drop width of course.

@brycepj i don't know which description you will follow, but i like the way you can see what your time zone is based of the location which is stated behind it.

either once

@markpundsack this will only be supported from https://gitlab.com/gitlab-org/gitlab-ce/issues/30675 so lets leave that out for now

With all edits it results in:

updated issue description

@dimitrieh Can you please kill "schedulement" in your mockups? It still says "Schedulement not set yet". "Schedule not set yet" would be sufficient. As far as my dictionary is concerned, "schedulement" is not a word. "Schedule" is both a noun and a verb.

Small thing, but we use American English in the product; can we also use American time? 04:00 is European or military time and looks really weird to an American. 4:00 am would be better.

@markpundsack oops! got ya! updated in description

mentioned in issue #22847 (closed)

Small thing, but we use American English in the product; can we also use American time? 04:00 is European or military time and looks really weird to an American. 4:00 am would be better.

This makes me way sadder that it should, but this is an inferior system. Can't we just take the high ground? Its also common for scientific publishing already.

@dimitrieh What is the value of showing "Last triggered" when you display the pipeline? The last triggered time will only show how inaccurate this system really is, so I feel we should hide it. Also, IMO we need the space for descriptions like "Monthly release schedule" which is an example that just doesn't fit right now.

@dimitrieh Setting active, or inactive is on the edit page right? Or would you want that to be a button under 'actions'

mentioned in merge request !10853 (merged)

clicking Cron syntax will open up a new tab with gitlab cron documentation (@axil is there existing docs where we can link to?)

What do you mean exactly with GitLab cron? I don't think we need to re-event the wheel :) Can we link to an external link? We have a couple of "official" options:

cron documentation

Reliable links have already been described at https://docs.gitlab.com/ce/ci/triggers/#using-scheduled-triggers. Please check the links "learn more about cron notation" and "see a list of timezones". Those links were picked from rufus-scheduler dosumentation.

What is the value of showing "Last triggered" when you display the pipeline? The last triggered time will only show how inaccurate this system really is, so I feel we should hide it.

@zj i think you are right! I am okey with hiding it!

Setting active, or inactive is on the edit page right? Or would you want that to be a button under 'actions'

I thought it was out of scope, but reading back it wasn't! Yes it should be on the edit page 😉 Something like this at the bottom:

What do you mean exactly with GitLab cron? I don't think we need to re-event the wheel :) Can we link to an external link? We have a couple of "official" options:

@axil Sounds good to me! (Can you add the link you choose to the issue description?) also see https://gitlab.com/gitlab-org/gitlab-ce/issues/30882#note_28093611

updating issue description

Sounds good to me! (Can you add the link you choose to the issue description?) also see https://gitlab.com/gitlab-org/gitlab-ce/issues/30882#note_28093611

@dimitrieh @dosuken123 I opted to use the wikipedia article as it contains all other links and is a reliable link in terms of not going down any time soon :)

Small update for the radio buttons as of https://gitlab.com/gitlab-org/gitlab-ce/issues/30675#note_27926967

Hides cron field when other radio option preset is selected

added docs-missing label

@brycepj @jschatz1 is any of you working on this? /cc @ayufan

yes

@dimitrieh any graphic for no pipeline view? Or use the same as other pipeline?

assigned to @zj

@jschatz1 @zj I recommend using the same graphic as in the helper text. As for the text, i'd change it marginally to:

close-up:

@hazelyang do you approve ? :)

Love it 😻

@dimitrieh I'm assuming it's okay to implement the target branch selector like other branch selectors in GitLab.com? We don't currently have a re-usable component for the issue-search-like search & dropdown.

@dimitrieh :thumbsup::thumbsup::thumbsup:

@brycepj yes i think so ;) also no worries if you get the pipeline graphic to be as beautiful. i have slightly different design for that in mind anyway!

mentioned in merge request !10917 (merged)

@dimitrieh What should we show in the pipelines table when there are no scheduled pipelines?

closed via merge request !10853 (merged)

mentioned in commit 66b225d4

What should we show in the pipelines table when there are no scheduled pipelines?

@brycepj see https://gitlab.com/gitlab-org/gitlab-ce/issues/30882#note_28584411

It is correct that this has not yet been implemented correct? The same for extra variables?

@brycepj also there are some non-similarities between implementation and design

vs

small note on wording: only first word gets a capital

I know we also have https://gitlab.com/gitlab-org/gitlab-ce/issues/30675, will you do this as part of that or does this need its own issue?

It is correct that this has not yet been implemented correct? The same for extra variables?

@dimitrieh When I saw that the "Pipelines" tab was highlighted in the mockup and that the full view wasn't included in the Issue description, I assumed that was an experiment that wasn't completely finished or wasn't decided to go in the final design. That's why I asked you what the blank state should look like here. You also commented earlier that:

no worries if you get the pipeline graphic to be as beautiful. i have slightly different design for that in mind anyway!

So I didn't know that was ever resolved.

And no, variables were not included in this iteration -- I don't know when that decision was made, but that's the message I got from @zj early on.

also there are some non-similarities between implementation and design

The most recent version of the UI was merged here (https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/11332) and will likely to be picked into stable shortly. So the screenshot above is a little out of date. Fwiw, I asked for your input here five days ago and never heard back -- I know these things can easily slip through the cracks though -- I should have followed up with you in Slack 😺

But yeah, if you don't mind opening an issue with a list of the discrepancies you'd like fixed that would be helpful. It was hard to know what aspects of the design to implement and what aspects to ignore, so if you can be specific about what you'd like improved that will help me know what to focus on.

And no, variables were not included in this iteration -- I don't know when that decision was made, but that's the message I got from @zj early on.

Variables were out of scope, which makes a nice addition, but we want to deliver story first and follow-up later.

We should have the separate issue for adding Variables support for schedule and tackle that orthogonally for everything else.

mentioned in issue #32568 (closed)

@brycepj

no worries if you get the pipeline graphic to be as beautiful. i have slightly different design for that in mind anyway! So I didn't know that was ever resolved.

this was about something else and is not that important :)

I created the following issues and assigned them to you:

See if you can fix them immediately or if they are for later releases 😉

cc: @ayufan

@dimitrieh thanks, just looked through them -- I appreciate the level of detail you included. I'll assign myself and start into them ASAP. ⭐

mentioned in issue #32767 (moved)

mentioned in issue gitlab#9317

Run CI/CD pipelines on a schedule Improving UI FE and UX

Resources

Issue Origin

Design

Next iterations could include

Related issues

CC/Call to actions

Designs

Child items 0

Activity

New design

Admin message

Admin message

Run CI/CD pipelines on a schedule Improving UI FE and UX

Resources

Issue Origin

Design

Next iterations could include

Related issues

CC/Call to actions

Activity

New design