-
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
fix(ci): make generation comment clearer #258
Conversation
✔️ Deploy Preview for api-clients-automation canceled. 🔨 Explore the source changes: d7abc04 🔍 Inspect the deploy log: https://app.netlify.com/sites/api-clients-automation/deploys/6231f09cc617ab0009b15bfd |
b5adceb
to
da2a9d8
Compare
✗ The generated branch has been deleted. If the PR has been merged, you can check the generated code on the |
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.
Best automation ever !
@@ -2,6 +2,11 @@ name: Setup | |||
|
|||
description: Setup CI environment. | |||
|
|||
inputs: |
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.
Because this file is quite different with minimal
, is it worth it to create another file instead ?
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 not sure how nested composite would behave but splitting the setup
file would definitely make sense. Might be worth investigating that
describe('cleanGeneratedBranch', () => { | ||
it('throws without parameters', async () => { | ||
await expect( | ||
// @ts-expect-error a parameter is required |
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.
You can pass undefined
to remove the @ts-expect-error
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.
It wouldn't be accurate as we actually don't accept undefined
, it's only here to make sure it throws
if (trigger === 'notification' || trigger === 'noGen') { | ||
return `${commentText[trigger].header} | ||
|
||
${commentText[trigger].body}`; |
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.
Maybe body
could always be a function to remove this if
.
const REPO_URL = `https://github.com/${OWNER}/${REPO}`; | ||
|
||
export default { | ||
notification: { |
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.
Can you give those object a type please ?
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.
Inferred type is enough here, we don't use it elsewhere
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 was saying that to have the same type between all objects, like all body
should be function
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.
Ah ok I see, I'm not sure it's necessary as it does not need a parameter. If you would like to make it consistent I have nothing against 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.
I think having the same type in the array make it more predictable and easier to maintain
🧭 What and Why
🎟 JIRA Ticket: https://algolia.atlassian.net/browse/APIC-378
Changes included:
codegen
CI🧪 Test