Automate template setup process via CI for GitHub users

[Ndpnt]

• Technical improvement

• Minor change

• Impacted areas: Setup script and CI workflows

• Details:

  • Automate template setup process via CI for GitHub users:
  • When creating a new repository by using this template on GitHub, the setup script is automatically executed by the CI on the resulting generated repository.
  • Improve accessibility by adopting less technical terminology:
  • Replaced "bootstrap" with "first-time setup," clarifying its purpose as a one-time project initialization, particularly useful for users unfamiliar with the technical vocabulary.
  • Decompose GitHub Actions monolithic workflow into specialized workflows:
  • Split the Country-Template workflow into three distinct workflows: build, validate and deploy enhancing clarity and organization.
  • Enhance accuracy of workflow triggers:
  • Trigger deployment exclusively when a PR is merged on the main branch
  • Trigger validation on PR events or as a dependency of the deployment workflow

• ---

These changes:

• Change non-functional parts of this repository: CI, setup script and documentation

The automation of template setup process via CI can be tested on my fork here

[Ndpnt]

This PR will imply to update the expected validations in the branch protection settings.

[MattiSG]

I have switched off required status for all status checks except check-version-and-changelog 👍

[Ndpnt]

One question though: I see that the current workflow layout has a nested build job, and it is the only nested one. Do you understand where this is coming from? Is there any way we can make it appear at the same level as other entries in the build?

I'm unsure why, and I don't know how to change it. My guess is that this arises because the build job is defined within the build workflow file, and this job is triggered only as a dependency of other workflows, not directly.

[MattiSG]

My guess is that this arises because the build job is defined within the build workflow file, and this job is triggered only as a dependency of other workflows, not directly.

That makes sense… let's try to find a workaround this UI limitation and rename one or the other to make it look clearer 🙂

[Ndpnt]

That makes sense… let's try to find a workaround this UI limitation and rename one or the other to make it look clearer 🙂

What do you think if we rename the job build into build-and-cache?

[MattiSG]

rename the job build into build-and-cache?

Very good idea, as indeed the goal is to cache and fill in the dependency for all other steps! Let's make sure that this is the name of the top-level entry though, so I assume this should be the name of the workflow and not job (but I'm not sure).

[Ndpnt]

Very good idea, as indeed the goal is to cache and fill in the dependency for all other steps! Let's make sure that this is the name of the top-level entry though, so I assume this should be the name of the workflow and not job (but I'm not sure).

I'm not sure to understand, what do you prefer build / build-and-cache or build-and-cache / build?

[MattiSG]

Thanks for pointing that out… I prefer build / build-and-cache even though I initially suggested the opposite 😅

[Ndpnt]

Thanks for pointing that out… I prefer build / build-and-cache even though I initially suggested the opposite 😅

Ok so I properly understood 😄. I also prefer build / build-and-cache

[MattiSG]

As discussed synchronously:

• The parallelisation between check-changelog and build is voluntary and I had already suggested it, in order to shorten the feedback loop for users.
• The deploy tasks are now only triggered on main and thus voluntarily do not appear on other branches. The dependency layout on a deployment branch can be seen on the source repository and below.