WIP: Add jobs to categories

changed milestone to %11.10

added Category:Auto DevOps devopsconfigure [DEPRECATED] + 1 deleted label

added 1 commit

084ee21b - Changelog entry for 27500

marked the checklist item Changelog entry as completed

	2 Warnings
	This merge request does not have any assignee yet. Setting an assignee clarifies who needs to take action on the merge request at any given time.
	You’ve made some app changes, but didn’t add any tests. That’s OK as long as you’re refactoring existing code, but please consider adding any of the ~backstage, ~Documentation, QA labels.

Reviewer roulette

Changes that require review have been detected! A merge request is normally reviewed by both a reviewer and a maintainer in its primary category (e.g. frontend or backend), and by a maintainer in all other categories.

To spread load more evenly across eligible reviewers, Danger has randomly picked a candidate for each review slot. Feel free to override this selection if you think someone else would be better-suited, or the chosen person is unavailable.

Once you've decided who will review this merge request, mention them as you normally would! Danger does not (yet?) automatically notify them for you.

Category	Reviewer	Maintainer
backend	Bob Van Landuyt (`@reprazent`)	Robert Speicher (`@rspeicher`)

Generated by Danger

changed the description

added 1 deleted label

@ayufan could you help me figure out this failure? These same templates were included in https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/26520 and I see no such failures there. Not sure how to address this but it seems that now with composable auto devops we could expect this failure everytime? Help is appreciated.

It seems that any job in Jobs that is walked and accessible should have proper stages configured. It seems that these do not.

For example the Jobs/Browser-Performance-Testing.gitlab-ci.yml is not a valid job, as:

it should have valid stage, this stage is not valid,
it should have a standard set of stages defined if adding additional one https://gitlab.com/gitlab-org/gitlab-ce/issues/59992

@danielgruesso the reason is that the specs rely on the GitlabCiYmlTemplate finder to get the list of templates to be tested. Though, this finder only return templates that belong to a defined category.

Hence, the Jobs/*.gitlab-ci.yml files where not fetched by this finder so were not tested in /spec/lib/gitlab/ci/templates/templates_spec.rb.

This is fully correct. If you decide to use Jobs/ it will not be matched, as this is also something that template: does not know about.

It is quite unlikely that you gonna have Jobs/ and then Pages/Jobs/, but this is very likely that we gonna have something Jobs/ and Security/ when these two folders are being use (we already had such case).

Consider, that we also don't present templates on UI that are in sub-folder, so as soon as we start showing them, we should ensure that they are complete. It means that adding the Jobs/ to visible set should make this templates to be useable when picked via New file.

@gonzoyumo but Security is indeed a category in EE and those template don't have the complete stages that this new condition is asking for. Why is that?

Consider, that we also don't present templates on UI that are in sub-folder

@ayufan We are indeed showing all the contents in the Security sub-folder.

So what would be a viable solution here?

those template don't have the complete stages that this new condition is asking for. Why is that?

@danielgruesso they do not need to to explicitly declare the default stages if they are just using a default stage. It is only when the jobs are using a non default stage that the template needs to redeclare all the default stages and the custom one.

e.g. our DAST template is using the custom dast stage, hence it declares:

stages:
  - build
  - test
  - deploy
  - dast

All our other templates are using the default test stage, so they don't need any declaration.

That's why only the BTP and Deploy job templates are failing here, because they respectively target the performance and review custom stages.

removed 1 deleted label

changed milestone to %11.11

mentioned in merge request !27511 (merged)

mentioned in issue #60144 (moved)

@ayufan any way to relax that requirement for contents of the Jobs folder? I see it's well-intentioned to not provide incomplete templates but we have to consider if that is more important than being transparent about what jobs we are using to construct Auto DevOps.

I think that the simpler is to make these jobs to include stages: and make them valid.

@ayufan since we don't have a mechanism to generate a gitlab-ci.yml file from multiple templates, two use cases come to mind that wouldn't fit if we include standard stages in all templates:

User clicks on drop-down to see templates names in order to use with include functionality. If all Jobs templates have the same standard stages this wouldn't work, for example:

User clicks on drop-down to copy/paste contents of template into new file to construct their own. user now has to remove all duplicate stages.

User clicks on drop-down to see templates names in order to use with include functionality. If all Jobs templates have the same standard stages this wouldn't work,

Exactly. This will not work.

The only way to make them work is to ensure that each of these jobs uses build, test, deploy that are implicit unless stages: are defined.

It means, that we could go a step further, but this still requires that these templates to be valid, but additionally we do require to never use stages: or any other global configuration that could be overwritten by any of the other templates. It means that only allowed to use stages would be one of build, test or deploy. Then, a user could overwrite the used stage in their top-level configuration file.

Technically, this should make everything nicely composable, but with need for overwrites at least in case of Auto-DevOps (but overwrites are quite easy to do).

I actually do like that idea, as it makes the composability much easier and much more bulletproof, but it puts more limitations on what is allowed to use as part of template syntax :)

@gonzoyumo WDYT?

Will close this MR in favor on following the behavior described here: https://gitlab.com/gitlab-org/gitlab-ce/issues/60144#note_162577774

all top-level templates are free to do whatever needed with stages: and global: configuration,

all sub-level are forbidden from doing that, as we plan to make them composable,

require that all templates are valid and complete,

require that all sub-level templates are composable, so follow rule 2.,

require that sub-level template never defines any of global configurations, like stages:, before_script:, etc.

all templates can extend global variables: as this is merged together,

require that each sub-level templates has to use one of the predefined stages: build, test or deploy,

if we reference composable template from our top-level template we always use full path, like Jobs/Build.gitlab-ci.yml,

This makes clear rules also for Auto-DevOps, as it is free to overlay all composable templates, as it is living in top-level directory.

Ideally, we should revisit all top-level if they should become sub-level ones.

closed

added groupconfigure [DEPRECATED] label

changed the description

added groupenvironments label and removed groupconfigure [DEPRECATED] label

WIP: Add jobs to categories

What does this MR do?

Does this MR meet the acceptance criteria?

Conformity

Performance and testing

Security

Activity

Reviewer roulette

WIP: Add jobs to categories

What does this MR do?

Does this MR meet the acceptance criteria?

Conformity

Performance and testing

Security

Merge request reports

Activity

Reviewer roulette