-
Notifications
You must be signed in to change notification settings - Fork 17
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
feat(ci): make ci push generated code #244
Conversation
✔️ Deploy Preview for api-clients-automation canceled. 🔨 Explore the source changes: 79d650f 🔍 Inspect the deploy log: https://app.netlify.com/sites/api-clients-automation/deploys/622f1d10e663db0008bd8659 |
99adf06
to
af4df2c
Compare
b3c61b7
to
a8d9aa6
Compare
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.
allez!
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 will really make the repo look automated :)
@@ -40,6 +40,115 @@ runs: | |||
shell: bash | |||
run: curl -L "https://repo1.maven.org/maven2/org/openapitools/openapi-generator-cli/5.4.0/openapi-generator-cli-5.4.0.jar" > /tmp/openapi-generator-cli.jar | |||
|
|||
# Restore bundled specs: used during 'client' generation or pushing the 'codegen' | |||
- name: Restore built abtesting spec |
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.
Why are those cached here ? I think we have duplication between bundled
and dist
, and if this needs to be cached I think it should be part of .gitignore
too, so that we don't have to gen them ourself
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.
Why are those cached here ?
They are cached as generated clients, for now the CI will only push bundled specs and generated clients. We shouldn't push them anymore too.
Ideally, we should have the same part for the CTS
codegen: | ||
runs-on: ubuntu-20.04 | ||
timeout-minutes: 10 | ||
if: ${{ always() }} |
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.
if: ${{ always() }} |
This is a no-op right ?
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.
Unfortunately, always seems to be as good as a promise hell.
We've introduced always
in our CI because the matrix does not return a failure/success status on empty matrix, removing the always
here will skip the codegen
(or any other job without always
after a matrix step) on empty matrix.
I think I found a workaround to make the matrix return a status, but I'll try to fix it an a later PR
env: | ||
CACHE_VERSION: '9' |
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.
We already have this variable in multiple files, this will lead to issues and incorrect use of cache if we don't update them at the same time, you think it's possible to have it inside a file like .cache-version
, and read it ?
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.
IIRC there's an issue with env from files in a composite action, but I can check!
* | ||
* @param headRef - The name of the branch to search for. | ||
*/ | ||
export async function cleanGeneratedBranch(headRef?: string): Promise<void> { |
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 function must not be exported, and you can remove the parameter headRef
, because it's meant to be used as a standalone (if it's imported into another file it will run cleanGeneratedBranch
)
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.
(I've resolved other two comments to keep the conv here)
Since this function either runs from the script with an env variable or from a function call with a parameter, I've went with this solution.
I can also inline it like you suggested in #244 (comment) and inlining the HEAD_REF
env var, I don't have a strong opinion so feel free to chose :D
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.
The solution that would make more sense to me is having the cleanGenerateBranch.ts
as a standalone script, and only accept the headRef as a cli parameter through process.argv
, that way there is no surprise, wdyt ?
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.
I'm fine with both actually, is that what you had in mind? b1d5dea
@@ -5,6 +5,8 @@ | |||
"build": "tsc", | |||
"createReleaseIssue": "yarn build && node dist/scripts/release/create-release-issue.js", | |||
"processRelease": "yarn build && node dist/scripts/release/process-release.js", | |||
"pushGeneratedCode": "yarn build && node dist/scripts/ci/codegen/pushGeneratedCode.js", |
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.
In general if the code needs to be build everytime it's better to use ts-node
, that will actually show errors in ts, and it feels cleaner IMO
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.
Yep indeed, but since it was like that already I've went with consistency, I'll change it in a next PR
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.
Much cleaner 👍
🧭 What and Why
🎟 JIRA Ticket: https://algolia.atlassian.net/browse/APIC-361
Changes included:
This PR adds a
codegen
GitHub action at the end of the CI process, which pushes the generated code to agenerated/<branchName>
branch and provide a comment for us to preview it.Stacked PRs:
The previously generated branch is deleted and the generation runs from the last commit, creating a new generated branch for the current one.
main
:Same logic as
stacked PRs
, but pushes to agenerated/main
branch, we can after that use it to open a PR and push tomain
for example.Other repositories
The logic would be similar to
main
, but push on an other repository based on the changes location.e.g.
clients/algoliasearch-client-javascript
changed, we push it toalgolia/algoliasearch-client-javascript
next
branch.Next steps
always()
: I initially removed it here chore: make cache keys cleaner #242, but it's in fact needed when a matrix does not have elements to run.🧪 Test
Preview on #245