-
Notifications
You must be signed in to change notification settings - Fork 16
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
Conversation
There was a problem hiding this 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 🙂
Co-authored-by: Matti Schneider <[email protected]>
Co-authored-by: Matti Schneider <[email protected]>
Co-authored-by: Matti Schneider <[email protected]>
Co-authored-by: Matti Schneider <[email protected]>
* openfisca/main: Fix changelog hierarchy Use PyPi token for deployment
Python `v3.9.9` is not available for Ubuntu `v22.04`
Update actions dependencies
This PR will imply to update the expected validations in the branch protection settings. |
There was a problem hiding this 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?
.github/workflows/deploy.yml
Outdated
branches: | ||
- main | ||
types: [ closed ] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unify syntax.
branches: | |
- main | |
types: [ closed ] | |
branches: [ main ] | |
types: [ closed ] |
.github/workflows/deploy.yml
Outdated
pull_request_target: | ||
branches: | ||
- main | ||
types: [ closed ] |
There was a problem hiding this comment.
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.
.github/workflows/deploy.yml
Outdated
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' |
There was a problem hiding this comment.
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 thatgithub.event.pull_request.merged == true
.
first-time-setup.sh
Outdated
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" |
There was a problem hiding this comment.
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 🙂
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 |
I have switched off required status for all status checks except |
Co-authored-by: Matti Schneider <[email protected]>
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 |
Very good idea, as indeed the goal is to cache and fill in the dependency for all other steps! |
I'm not sure to understand, what do you prefer |
Thanks for pointing that out… I prefer |
Ok so I properly understood 😄. I also prefer |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As discussed synchronously:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🚀
Country-Template
workflow into three distinct workflows:build
,validate
anddeploy
enhancing clarity and organization.main
branchThese changes:
The automation of template setup process via CI can be tested on my fork here