Plan for initial codebase

To ensure that the validation and linting jobs are all run, the 3.x and 4.x branches should contain at least one file of each of the following types:

• .php
• .js
• .css
• .yml
• .md

In Drupal 7 testing, the only linting job is PHPCS so these extra file types are not needed.

First pipeline was run on D10. Four out of the six linting jobs were run.
https://git.drupalcode.org/project/gitlab_templates_downstream/-/pipelin...

• composer-lint and cspell are always run (unless specifically skipped) so that is OK
• phpstan was not run because there are no .php files (ok)
• stylelint was not run because there are no .css files (ok)
• eslint was run because we have one .yml (ok)
• phpcs was run - there are no .php files but this is not in the jobs rules (needs to be checked)

We can use the recognised version naming conventions

I am happy with that, but I'd also be ok with a non-standard setup where we maybe use long-verbose-names for the branches so that we know exactly what the branch is about.

With the standard names, we'd need probably a main branch with a readme.md where it explains each branch.

Yes using longer verbose names might be better, it was just that I was expecting we should mimic real D7 and D10 projects as much as possible, But you are right that the branch names are not salient to the testing purpose of the project.

So using the names I suggested in the summry, would they instead become

• d7-no-composer
• d7-with-composer
• d10-with-d9-legacy
• d10-plus

or something like that? I have only created 7.x-1.x so far, so will halt until we get these names agreed.

Slight change suggestion:

• d7-basic
• d7-composer
• d9-plus
• d10-plus

Prefix should be the module's minimum (d9, d10, d11) and then whatever else makes sense after.

Thanks, yes those are better. I have pushed d7-basic and d9-plus to see how it goes, before creating the other two.

For the README.md we do not want to maintain four versions, do we? All info can be in one file, telling about all the branches. I have set 'd9-plus' as the default branch for now. But maybe 'd10-plus' will become the default when I make it, so the readme can be stored there (and there alone?), with the other three just having a url to that file? We want to make it as easy for us as possible.

How about main as default branch with only the readme file?

OK, yes. It might be useful to have a branch which does not run a pipeline. In time that could be the default branch, but while developing it is useful to have one of the active branches as default to that a pipeline is run whenever a push is made.

To prove the d7-basic test coverage, I submitted a pipeline via UI with gitlab_templates_ref 1.7.0 and it failed as expected. This shows that we had not catered for a missing composer.json, which is now fixed in 1.7.1
https://git.drupalcode.org/project/gitlab_templates_downstream/-/pipelin...

I have created 📌 Add Gitlab Templates Downstream testing project Active and triggered the first two downstream pipelines sucessfully.

it is useful to have one of the active branches as default to that a pipeline is run whenever a push is made.

We can tweak/override the rules on any branch so the CI runs on push for that branch.

Great to see the two projects connecting and proving that we can control multiple cases from this project.

It's a great start!

Feedback:
- "main": it doesn't probably need a ".gitlab-ci.yml" file, unless we want to trigger the branch pipelines from there (maybe a daily scheduled task). I'd make this branch the default branch, it shouldn't interfere with running pipelines as/when needed on the other branches.
- Then each branch's readme file should be about that branch/project only and explain briefly the case/s that it covers.
- Each branch's "gitlab-ci.yml" file might have specific overrides for when to run the pipeline if the default setup won't trigger then on commit.

I have changed 'main' to be the default and removed the README from each of the other branches before I saw your latest comment. I thought that in the first instance it would be simpler to have just one readme. But if you want one on each branch I can do that. The 'main' readme can be reduced to minimal, although at the moment there is not much to add anyway.

One downstream pipeline failed, d7-composer, so I will look at that. I had not run that branch directly here.
https://git.drupalcode.org/project/gitlab_templates_downstream/-/pipelin...

"main": it doesn't probably need a ".gitlab-ci.yml" file, unless we want to trigger the branch pipelines from there (maybe a daily scheduled task).

Initially I was going to say that we need to run the GTD pipelines everyday, as there should be nothing that changes in them that we do not do ourselves, and we will be triggering them during gitlab templates MR testing quite frequently. But maybe it would be reassuring to know that the infrastructure is always OK and the pipelines are green, so that if we get a failure from a downstream then we know it has to be caused by the MR and not a previously existing error.

I think it looks cool to just have the minimal readme on main, and then each module just have the module's code itself. I don't think we need per-branch readme at all. Thanks for that.

Happy to get that daily task from GTD. Maybe we can set up the file in main to trigger the 4 branches automatically (downstream style), that way we only need to set up one daily task.

As for the composer error. We don't get Drupal 7 via composer, so the line here ( "drupal/core": "^7") fails.

We can just try it to bring external dependencies, like here on the "API" project or drupal modules, like here in the "Scheduler" project. Anything except for core D7 🙂

Just reviewing this issue to see if there anything else we need to do.

From #2
We have files with all those extensions except .css and .md.
I have raised 📌 Add test coverage for stylelint job Active for the css checking.
Only the 'main' branch has a .md file, but this is not triggered in the downstream pipelines. Do we need to add a .md file into the branches? Some phpcs checks are done on .md files. Or we could add 'GTD Main' into the downstream pipeline list? I was thinking that we don't have downstream coverage of the 'pages' job, so maybe we could use the main branch for that?

From #3

• eslint now also checks the Nightwatch .js file in addition to the .yml file. Running with _ESLINT_EXTRA = --verbose, search for yield: to show the files found and whether they were tested. It shows that two are checked gitlab_templates_downstream.info.yml and downstream-one.js
• we now get PHPStan jobs because we added .php files for the phpunit tests
• stylelint will be covered by the above issue
• phpcs was run even though there were no files to check. Running with _PHPCS_EXTRA = -v shows 0 files - see this example on 'main' https://git.drupalcode.org/project/gitlab_templates_downstream/-/jobs/47... Maybe there is a mismatch between the job rules and the list of php files we derive. Could add issue in Gitlab Templates to investigate this

The problem in #15 was fixed a while ago.

I have added a paragraph about the git alias for comparing against the parent. Here is the updated file in MR14. Do I need to add the explanation as per in slack ?

Yup, maybe we can use the "main" branch to generate a small documentation site, where we have a page for each branch explaining what each branch is about. Something short but that will be enough to check md files and the pages job.

Once done we can add it to the downstream files in case we do changes to the "pages" job.

Given that you created the two follow-ups above, maybe we can create one for the "pages" documentation files for this project.

I added some minor feedback to MR14.

Thanks. I have created 📌 Add documentation .md files to test the pages job Active and responded in MR14

As we have the last follow-up issue I think we can set this issue to fixed.

We can contiue to use MR8 as a general testing merge request, to try out things or use a specific Gitlab Templates MR. It does not matter that this issue will eventually become closed.

Agree, we can close and keep using MR8 as needed.
Thanks!

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