Add source for feedback cloud func #62
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
✅ Deploy Preview for molevolvr ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
|
@falquaddoomi for review when you get back. I didn't bother to scaffold out any kind of auto-deployment to GCP for this script. I figured that it's such a short and simple script (~50 lines) and will probably not change much, that it wasn't worth it. |
falquaddoomi
approved these changes
Jul 23, 2025
|
This definitely shouldn't block this PR, but something that occurred to me afterward is that these issues will be created as the user account for which you created the access token. That's definitely not a problem, but we could alternatively create a GitHub App; the app would be added to the target repo, then we'd authenticate as the app to get a token that we'd then use to create issues. |
Indeed, it's not ideal. I'm fine leaving it as my PAT for now, but eventually I think we should do either an app or a PAT under Janani's name. I would like to move from my personal GCP project to the cuhealth-ai one, or ideally (later) a RaviLab-controlled GCP, before merging though. |
|
In the latest commit:
I'm still keeping the GitHub PAT under my name, but I lost the previous temporary one, and when creating a new one it now said it has to request approval from the org owner. So it won't work until Janani approves it. |
vincerubinetti
added a commit
that referenced
this pull request
Sep 10, 2025
Changes the method of deploying cloud funcs to align with CU OIT's preferred permissions setup for GCP, which forces us to do the deployment through a script with the GCP CLI instead of through the web console UI (where it is currently impossible to specify separate service accounts for the build and runtime). As I mention in [this comment on PR #62](#62 (comment)), we're still not doing automatic deployment of this script (yet) since it's very small and unlikely to change. @jananiravi You'll see in this diff that a `GITHUB_TOKEN` is required so that an issue can be created on this repo. It also determines what account the issues will be created by. There are basically three methods we can choose from: 1. You, as the `@jananiravi` username, generate a fine-grain personal access token (PAT) that only has permissions to create issues, and only on this repo. The feedback form would then create issues as if you had created them. 2. We create a new GitHub user like `@molevolvr-bot`, keep track of its login info, and generate a PAT with that. The feedback form would then create issues as the bot account, which we could give a little 🤖 avatar so people know it was automated. 3. We make a [GitHub App](https://docs.github.com/en/apps/creating-github-apps/about-creating-github-apps/about-creating-github-apps). The feedback form would then create issues as the App. 1 isn't ideal because your username will get much more notifications (which maybe you want), and it's unclear at first glance (other than the `feedback` label that will be auto-added to the created issue) that it was an automated thing. 3 is imo overkill for what we are trying to do. It involves more set up, more secrets, and a [more involved auth handshake](https://github.com/octokit/auth-app.js/?tab=readme-ov-file#usage-with-octokit) than what we currently have in the `/feedback/index.js` script. Apps allow more complex things like allowing multiple repos to install it, multiple users to authenticate with it, and acting on behalf of users, when all we really need is issue write permissions for a single repo. Therefore, I recommend option 2. If you're agreeable to that, I can create it, add its username/password to the software team's vault, share it with you so you have ownership access, and do the deploy with its PAT. <details><summary> Gemini's summary of the benefits of making a GitHub app, with my own commentary</summary> > Granular Permissions and Security: • GitHub Apps have their own independent permissions, allowing for highly specific access control to resources without granting broad user-level permissions. Fine-grained personal access token's alleviate this. They allow, for example, only the ability to write issues to a specific repo. > • They utilize short-lived installation access tokens, reducing the risk window if a token is compromised, unlike PATs which can be long-lived and grant broader access if leaked. • Permissions are associated with the app installation, not a specific user, ensuring continued functionality even if a user's access changes. PATs can be leaked. However we have the `.env.local` file where ours is supposed to be added in `.gitignore`, and we have GitHub's built-in push secret protection enabled, and if a PAT happens to be committed, we can revoke it immediately. > Scalability and Management: • GitHub Apps are designed for integrations and services that need to interact with multiple repositories or organizations. • They can be installed on organizations and repositories, providing a centralized way to manage access for automation and tools across a team or company. • The lifecycle of a GitHub App is separate from individual users, making it more robust for organizational automation. We don't need this. >Dedicated Identity: • GitHub Apps act as "service accounts," operating with their own identity on GitHub, distinct from any individual user. • They do not consume a GitHub seat within an organization. Option 2 allows us to have a "bot" identity for these cloud functions. </details>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Followup to #56 and #61. Adds code for a google cloud function that creates an issue on a particular repo.
Currently this is setup under my own personal GCP project, and hooked up to a test repo under my name (which I'll delete later). You can test by opening the webapp, adding
?mock=falseto the url (to make the app make real network requests), submitting the feedback form, and (hopefully) watching it appear at https://github.com/vincerubinetti/test/issuesBefore merge, we should re-follow the setup instructions I've included but with university/Ravilab-associated tokens/repos/gcp projects/etc.