Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Automate template setup process via CI for GitHub users #143

Merged
merged 42 commits into from
May 3, 2024

Conversation

Ndpnt
Copy link
Collaborator

@Ndpnt Ndpnt commented Apr 26, 2024

  • 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 Ndpnt requested a review from MattiSG April 26, 2024 13:35
Copy link
Member

@MattiSG MattiSG left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for this work! It's going to significantly improve the first time setup experience 😃

Many of the GitHub Actions referenced are outdated, and I made line-by-line remarks.
I believe it is worth including their updates in this PR, as it is usually quite painless to do, but I am totally fine if you prefer to separate the version upgrades in a separate PR. It should still be done as part of the work we do now on CI maintenance and improvements 🙂

.github/workflows/build.yml Outdated Show resolved Hide resolved
.github/workflows/build.yml Outdated Show resolved Hide resolved
.github/workflows/build.yml Outdated Show resolved Hide resolved
.github/workflows/build.yml Outdated Show resolved Hide resolved
.github/workflows/build.yml Outdated Show resolved Hide resolved
.github/workflows/deploy.yml Outdated Show resolved Hide resolved
.github/workflows/deploy.yml Outdated Show resolved Hide resolved
.github/workflows/deploy.yml Outdated Show resolved Hide resolved
.github/workflows/validate.yml Outdated Show resolved Hide resolved
.github/workflows/validate.yml Outdated Show resolved Hide resolved
@Ndpnt
Copy link
Collaborator Author

Ndpnt commented May 3, 2024

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

Copy link
Member

@MattiSG MattiSG left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Beautiful! 🤩
Thank you for this cloud first time setup, and for the overall upgrades to the CI pipeline! I could have stayed more focused on the main goal of this changeset in my comments, apologies for that.
It is the same with the bunch of comments I make here now. I will apply some of the changes in wording myself, especially when they touch upon pre-existing content.

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?

image

.github/workflows/build.yml Outdated Show resolved Hide resolved
Comment on lines 5 to 7
branches:
- main
types: [ closed ]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unify syntax.

Suggested change
branches:
- main
types: [ closed ]
branches: [ main ]
types: [ closed ]

.github/workflows/deploy.yml Outdated Show resolved Hide resolved
Comment on lines 4 to 7
pull_request_target:
branches:
- main
types: [ closed ]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't we deploy on any push to main, even if they did not originate from a merged pull request? 🤔
This would ensure a consistent mapping between commits on main and deployments, and simplify the code by removing the need to check if: github.event.pull_request.merged == true.

If changed, this should be reflected in the CHANGELOG.

deploy:
runs-on: ubuntu-22.04
needs: [ validate, check-for-functional-changes ]
if: github.event.pull_request.merged == true && needs.check-for-functional-changes.outputs.status == 'success'
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This condition is redundant since check-for-functional-changes already checks that github.event.pull_request.merged == true.

.github/workflows/deploy.yml Outdated Show resolved Hide resolved
.github/workflows/first-time-setup.yml Show resolved Hide resolved
.github/workflows/first-time-setup.yml Outdated Show resolved Hide resolved
README.md Outdated Show resolved Hide resolved
Comment on lines 106 to 109
echo -e "${PURPLE}* ${PURPLE}Remove single use \033[0m${BLUE}first-time-setup.yml\033[0m${PURPLE} GitHub Action\033[0m"
git rm .github/workflows/first-time-setup.yml > /dev/null 2>&1

echo -e "${PURPLE}* ${PURPLE}Remove single use \033[0m${BLUE}first-time-setup.sh\033[0m${PURPLE} script\033[0m"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's group them and reduce the amount of logs we expose our users to 🙂

Suggested change
echo -e "${PURPLE}* ${PURPLE}Remove single use \033[0m${BLUE}first-time-setup.yml\033[0m${PURPLE} GitHub Action\033[0m"
git rm .github/workflows/first-time-setup.yml > /dev/null 2>&1
echo -e "${PURPLE}* ${PURPLE}Remove single use \033[0m${BLUE}first-time-setup.sh\033[0m${PURPLE} script\033[0m"
echo -e "${PURPLE}* ${PURPLE}Remove single use first time setup files\033[0m"
git rm .github/workflows/first-time-setup.yml > /dev/null 2>&1

@MattiSG
Copy link
Member

MattiSG commented May 3, 2024

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

@Ndpnt
Copy link
Collaborator Author

Ndpnt commented May 3, 2024

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?

image

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.

Co-authored-by: Matti Schneider <[email protected]>
@MattiSG
Copy link
Member

MattiSG commented May 3, 2024

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
Copy link
Collaborator Author

Ndpnt commented May 3, 2024

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
Copy link
Member

MattiSG commented May 3, 2024

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
Copy link
Collaborator Author

Ndpnt commented May 3, 2024

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
Copy link
Member

MattiSG commented May 3, 2024

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

@Ndpnt
Copy link
Collaborator Author

Ndpnt commented May 3, 2024

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

@Ndpnt Ndpnt requested a review from MattiSG May 3, 2024 15:12
@Ndpnt Ndpnt enabled auto-merge May 3, 2024 15:13
Copy link
Member

@MattiSG MattiSG left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The code LGTM, but I spot something odd in the workflow view when applying this changeset, where the dependencies seem to be wrong.

Before

image

After

image

@MattiSG
Copy link
Member

MattiSG commented May 3, 2024

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.
image

Copy link
Member

@MattiSG MattiSG left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🚀

@Ndpnt Ndpnt merged commit 717800a into openfisca:main May 3, 2024
5 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants