Create a shared GitHub bot for cancerDHC organization

[joeflack4]

Description

We want to automate our devops (developer operations) workflows using GitHub actions. Sometimes this requires an agent (bot) in order to do things like running builds and create commits, or logging into a server and run some code.

Some of us (Dazhi, Gaurav, and I) thought it might be a good idea to have a single GitHub account which will act as the bot to do any of these automated tasks in any of the cancerDHC repositories.

Current responsibilities

For now, the only responsibility of this bot that I'm familiar with in detail is the ccdh-model <--> terminology-service integration.

What task it carries out
This bot updates the ccdh terminology service based on recent changes to the ccdh model. Then, since the ccdh model partially depends on the terminology service, the bot runs an action which updates the ccdh model as well.

What triggers this task
There is a placeholder GitHub action in the ccdh model repository. When this is finished, it will take any recent changes from the google sheets version of the ccdh model and update the .yaml model.

I know that there are other bots in cancerDHC, for example the one that did a build when I made a pull request to the linkml-model-template repo. It looks like the bot's commits have since been removed.

I don't know what other bots might currently exist and what their responsibilities are for any other cancerDHC repositories. @gaurav if you could add anything you know or chime anyone in who knows more.

Future responsibilities

I'm not immediately sure of any future responsibilities for the bot, but we should add more details here. @dazhi Is there anything else you wanted to add this?

Action items: list

• 1. Bot credentials: Decide on bot name and create Gmail and GitHub accounts for it.
• 2. Share creds: Share credentials with 1+ people who would need them (So far: Dazhi, Joe, Gaurav, Moni).
• 3. Access token: Create personal access token, based on current responsibilities.
• 4. Secrets: Create any secrets needed at the organization level, based on current responsibilities.
• 5. Future responsibilities: Determine any future responsibilities.
• 6. Future tokens/secrets: Update access token and create additional secrets if/as needed for new responsibilities.
• 7. Future NCI takeover: Need to pass bot creds and anything else NCI needs when they take over the cancerDHC organization.

Action items: further details

1. Bot credentials

So far, we have a temporary bot for our current purposes for the terminology service mainly. It has its own Gmail account, [email protected]. This [email protected] is also the GitHub username. This account has been given write access to the ccdh terminology service and ccdh model repos. We've created a personal user access token for this account and set the key for it as a secret called DOCKER_USER_TOKEN_LIMITED, which has been set for both of those repos.

We should probably create a new Gmail/GitHub account for a new bot. Maybe something like [email protected]?

3. Access token

From what I understand, the only checkbox which we should need to check for our current purposes is the "repo:status" one.

4. Secrets

Here's the secrets we have set up for the ccdh-terminology-service repo. The two secrets related to the bot user would ideally be moved to the organization level, and then they can be deleted from any repository settings where they currently reside. Theoretically, this makes it easier to manage the bot and its secrets.

[gaurav]

I don't know what other bots might currently exist and what their responsibilities are for any other cancerDHC repositories. @gaurav if you could add anything you know or chime anyone in who knows more.

As far as I know, there are no bots being used anywhere within CCDH repositories that we have developed ourselves. There are some GitHub Actions that generate commits in the LinkML repository (https://github.com/cancerDHC/linkml/tree/main/.github/workflows) -- we don't really use these ourselves, but they run as continuous integration tests when merging code back into the original LinkML repository, so they're helpful that way.