-
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
chore(ci): authenticate release issue by approval comment #316
Conversation
✅ Deploy Preview for api-clients-automation canceled.
|
✗ The generated branch has been deleted.If the PR has been merged, you can check the generated code on the |
|
||
const { data: members } = await octokit.rest.teams.listMembersInOrg({ | ||
org: OWNER, | ||
team_slug: TEAM_SLUG, |
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.
Although I get the idea, I wonder if it's good to check if it's a team member.
The end goal of this project is to let anyone from the company contribute to our clients, which would not match this condition.
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 think it's still okay. Anyone can open pull-requests and contribute to the code base, but only us can trigger releases. What do you think?
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 anyone at algolia should be able to release ?
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 would still be the bottleneck, IMO anyone from the company should have the rights to do it, we are just here to make sure it works well
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 don't we start with a small scope and expand later if there's a demand and if we think it makes sense to allow them to trigger releases? Anyway we can replace this small piece of code quite easily if we want.
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 I think it's fair at the moment to start with only us. We want anyone to contribute but it's very unlikely that we want unattended release
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.
Ok, I was mostly pointing it out but let's not forget about this
scripts/release/process-release.ts
Outdated
const octokit = new Octokit({ | ||
auth: `token ${process.env.GITHUB_TOKEN}`, | ||
}); |
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 could be in some common file
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 convinced on this. If we were to abstract all the octokit-related functions, then it'd make sense. But having only this part abstracted in a common file, I don't see much value. Besides, we have only two occurrences of new Octokit()
across the code base. We could do it when there's a third time ;)
https://en.wikipedia.org/wiki/Rule_of_three_(computer_programming)
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 count 3 ahah
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.
ahhhh you win. I somehow saw only two.
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.
💪
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.
scripts/release/process-release.ts
Outdated
issue_number: Number(process.env.EVENT_NUMBER), | ||
}); | ||
|
||
return 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.
Should we fail if we can't find the body
? This seems critical
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 don't know why octokit provides such type definition, but according to their rest api docs, it doesn't mention anything about body
being optional in the response. Even if it's not there, an empty string won't be a problem, because we need to parse the text and then proceed any release. And the empty string will prevent any further action.
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.
Yes but it's better to bail early rather that doing a bunch of work that could fail later and don't know where the error is coming from, unless it's all silent in the end
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.
Yeah it makes sense 097026e
scripts/release/process-release.ts
Outdated
|
||
return comments.some( | ||
(comment) => | ||
comment.body?.toLowerCase().includes('approved') && |
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 comment.body?.toLowerCase().trim() === 'approved
would be safer
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.
Yeah it should be more stricter. 1c66be4
@@ -18,6 +21,12 @@ export const MAIN_PACKAGE = Object.keys(clientsConfig).reduce( | |||
{} | |||
); | |||
|
|||
export function getOctokit(githubToken: string): Octokit { |
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 don't need to build a new octokit everytime, this should be a local variable
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.
What if we want to pass a different github token? I think it's easy to maintain stuff in common
without directly accessing process.env.xxx
.
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.
Small comment but looks good otherwise!
@@ -18,6 +21,12 @@ export const MAIN_PACKAGE = Object.keys(clientsConfig).reduce( | |||
{} | |||
); | |||
|
|||
export function getOctokit(githubToken: string): Octokit { |
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.
Unless we have different GH tokens, we can have a variable for 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.
ah bah what Pierre said
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.
Environment variables travel through process-release.yml -> process-release.ts, and I don't think it's good to have code accessing environment variables directly inside common
, because we don't know where the functions in common
can be used, and we cannot ensure if the env var exists.
|
||
const { data: members } = await octokit.rest.teams.listMembersInOrg({ | ||
org: OWNER, | ||
team_slug: TEAM_SLUG, |
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.
Ok, I was mostly pointing it out but let's not forget about this
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 go !
* chore(ci): authenticate release issue by approval comment * chore: fix lint error * chore: clean up * chore: validate comment body strictly * chore: early return if body does not exist * chore: extract octokit generation * chore: remove unused import
🧭 What and Why
🎟 JIRA Ticket: https://algolia.atlassian.net/browse/APIC-315
Changes included: