Hide variables that should not be overridden

If you really dont want users override these, you could remove them from the template and set them only in the docker image.

Status "needs review" ... is there a MR? I don't see any. Or is it "needs review" for the question you put in #2

Also in the subject "Hide variables that should be overridden" should that read "Hide variables that should be overridden"

Yes, what needs review is the idea proposed in #2 to not define certain variables in the templates, but to bake them directly into the container images. There's no MR for that, but it still needs consideration before it's worth spending time trying to implement anything.

p.s. I was wondering what the _ prefix was for, and if I should use it for my customizations or not. That'd be great to document in some of the default templates somewhere. Not sure if that's scope creep for this issue, or if it should be a follow-up.

I think we should first get a list of the variables that we don't want users to change. If this list is: "all of them without _ at the beginning" that's fine too. Tho the naming might be confusing because the SKIP_* variables don't start with _ and are meant to be changed by maintainers as needed, I think.

Since users could choose not to even use the templates at all and have their full customized gitlabci file, I don't think we need to over-worry about this. I think adding/updating descriptions might be enough. If a maintainer makes an override it will be a conscious decision.

If it turns out that it is only the SKIP_* variables are the only ones intended to be modifed but do not start with _ then we could create underscore versions of those and deprecate the old non-underscore versions. Could even do some BC work so that if the non-underscore version was used, we give a message and set the new variable accordingly. I

Then going forward we'd be able to stick to the rule that only variables starting with _ should be modified.

Note that variables set by the DA in the admin UI will take precedence in many cases.
https://docs.gitlab.com/ee/ci/variables/#cicd-variable-precedence

1. Trigger (not using these) / scheduled / manual pipelines variables have the highest priority.
2. Then project variables, which project maintainers can set.
3. Then group / instance variables, which the DA can set.
4. The dotenv / .gitlab-ci.yml / predefined variables. ".gitlab-ci.yml" variables is what most people will try to change.

Note that people using 1 and 2 might be more advanced users and should really know what they are doing.
Most people will be in scenario 4, and whilst they can override many things, they won't be able to override variables set in 3 by the DA.

So maybe this is an issue that we don't need to worry about?

In 🐛 _GITLAB_TEMPLATES_REF value in variables needs updating, and provide override variables for Curl Fixed we are introducing two new variables and they do not start with an underscore. Following on from the comments in #5-7 the variables.yml file has a mixture, and now would be a good time to make some decisions and standardize the policy (if we want to) before too many more contrib modules start using gitlabci. We can provide a BC layer for any variable names which we have to change.

I don't anticipate many more new jobs nor new variables. We might need to live with the ones we have now as we have them.

In the variables file: https://git.drupalcode.org/project/gitlab_templates/-/blob/main/includes...
We have:
- First group which starts with underscore for probably the most common tweaks for the jobs like Drupal version, php version, database type...
- Then the SKIP_ ones.
- Then the OPT_IN_ ones.
- Then LENIENT_ALLOW_LIST and COMPOSER_PATCHES_FILE which should probably start with _ (as it is configuration for the composer jobs) but don't <=== I only see an inconsistency in here.

Then a whole bunch of variables that we don't want changes to:
- _CONFIG_DOCKERHUB_ROOT
- CORE_ variables
- Database related variables
- Some constraints

And finally variables to test downstream and merge requests or fixed tags.

So at this point, I only think we have a couple of variables that don't follow the pattern. We could do a deprecation job for them or just live with them as they are.

Should we follow up with an issue for the previous or just close with "Won't fix"?

I also was thinking about a deprecation job to allow us to rename the incorrect variables if any are used and have non-blank value. The job can still end green, so we do not draw fire from those who have a green pipelines :-). It can be a .pre job, could even be one per variable, with the varibale name displayed, so it is very easy to understand what it is. I would like the OPT_IN and SKIP variables to also start with _ because they are for end users to modify.

Can do that here, we don't need a follow-up issue, do we? Or did you mean that this issue stays for hiding the variables that should not be overridden?

Probably do the deprecation as child issue. As for hiding the variables, i just don’t think that’s possible at this point and it’s really ok. So this issue could be closed.

I wouldn’t touch the SKIP_ nor OPT_IN_ variables at this point. Those are just switches (on/off) rather than job-specific open options, and they are probably the most used variables since day 1. They are in their own category.

We can reuse the .pre job we had for SKIP_COMPOSER and add the patches+lenient variables there (through the child issue).

OK, if the hiding is not possible (yet) then yes, we close this issue and do the deprecations in a separate one.

I wouldn’t touch the SKIP_ nor OPT_IN_ variables at this point. Those are just switches (on/off) rather than job-specific open options, and they are probably the most used variables since day 1. They are in their own category.

Ah, that's a great explanation. I like that, and very happy now to leave them alone.

Closing this issue and created #3426292: Deprecate and rename some variables that were wrongly named → to address the inconsistency found in #10.

We have another proposed way to hide the 'do not modify' variables and this issue is the best place to continue the work I started on #3441816-57: All variants run the same Drupal version when the pipeline is triggered via web →

MR197 is ready for initial review and feedback. Comparing the old and new files directly is not straight-forward due to the value: moving, but I have taken local copies of both, and wrangled them to make a compare work, and the values have all been set the same as before.

Pipeline test
https://git.drupalcode.org/project/scheduler/-/pipelines/164204

I did a really minor fix to the code.

The MR looks good. I like it because we are still supporting the "hidden" variables overrides (for advanced users) but we are also simplifying vastly the pipeline form offering much fewer variables.

RTBC.

Thanks. Your change is good. Here's a collage of screenshots showing the new reduced form. It was only 3 1/2 screens, but previously is was 10 1/2 screens. A few variables are not showing in my screenshot because I have them in the .gitlab-ci.yml file. So it is probably 4 screens compared to 10.5. That's still a nice % reduction.

Merged! Thanks for this.

Re #2, I think this would be the issue to do it #3440568: 2.x: Reduce number of variables in GitLab CI Templates → , but as that'd be a breaking change, it'd only be considered in a 2.x scenario.

Automatically closed - issue fixed for 2 weeks with no activity.