CI and Software Quality

@crondinini has done a great job getting us started with software quality checks, introducing a testing approac and linting with tsc and ESLint. These checks run on every PR using GitHub Actions and are reported as part of the PR which is really helpful.

CD

The application is currently deployed to a Heroku account that I setup for this project. The code has so far been deployed manually from a forked repo, to which Heroku has been granted access.

Issues

In the Heroku project setting it is possible to connect to a GitHub repository, after which manual or automatic deployments can be made. To enable this integration Heroku requests permissions at an organisation level.

By requesting this approval, you are asking owners of the Developer-DAO organization to allow this application to access private organization data and modify public organization data.

This feels like it might be too intrusive for integrating to this organisation, so we have not requested permission.

Options

1) Heroku -> GitHub integration

If the integration with Heroku and the permissions that it requests are deemed acceptable by the core maintainers of this organisation, then we could go ahead and setup automatic deployments this way.

2) GitHub Actions - Heroku API

It is possible to setup an Action that deploys to Heroku on every push to a specific branch.
#16 Is a PR that would add such an action.
Additionally we would need to configure some secrets in the project to support connecting to the Heroku API to perform the deployment.

secrets.HEROKU_API_KEY
secrets.HEROKU_APP_NAME
secrets.HEROKU_EMAIL

3) Git Push

It is possible to add a Heroku application as a remote on a git repo and push code to perform a deployment. This would require a process that could checkout the repository and push it to Heroku. I don't know if this is something that can be done in GitHub Actions, but is something I have configured previously in CI systems like Jenkins, Bamboo, etc.

Heroku has a document outlining 6 options for deploying where some other options are discussed. The only other one that might be of interest is dockerizing the application, but I don't know how well this would work with the heroku free plans.

@AidenMontgomery
Wanted to get discussion going here on which we should be working off of? It looks like you've, well....Extended....The addResource file. Should we just start working off of that one?

I didn't catch this in the merge.

Hi yall! 👋

I wanted to open this issue as sort of a mirror of #1. I agree with @fiigmnt's proposal that we should merge devie-bot and discord-resource-bot.

I'd like to extend from his proposal by proposing that we take the following actions:

• Since discord-resource-bot has an ecosystem already (events, commands, tooling, TypeScript support, beginnings of a test framework, etc.) while devie-bot is currently a single event, open a PR to discord-resource-bot adding the devie-bot event
• Merge permissions for both bots into Resource Bot
• Delete the devie-bot branch & rename this repo to devie-bot
• Rebrand Resource Bot to Devie

I think these changes would be less effort than merging all of discord-resource-bot into devie-bot while retaining the more general-purpose and friendly branding of Devie.

What do yall think?

If we'd like to go this route, I'll break the tasks above into sub-tasks so we can tackle them one-by-one.

Problem

When adding a new Resource the Author field is currently required. Currently the list of Authors is restricted to 25 as this is the maximum number of options that can be listed in a Select Menu for discord. Discord documentation

We need a new approach for selecting Authors as part of the /add-resource command.

I have thought about a few approaches that could be taken, but other ideas are welcome.

1) Make Author Optional

This would make it possible to add Resources without an Author and therefore allow submissions to continue.
Pros
Simple change
Immediately allows submissions of articles where the Authors are currently not listed
Cons
Data quality is reduced
Authors should be searchable

2) Add Paging Options

Change the first (apart from the first page) and last options in the Select Menu to be paging selections
Pros
Allows all Authors to be listed (eventually)
Possibly a simple code change
Cons
Finding an Author near the end of the list will take a long time

3) Create an index strategy

Sort all of the Authors into buckets, with a maximum of 25 entries at each level, e.g.

A-B
|-> Aa - Ag
  |-> Aaron Aardvaark
      Aaron Smith
      Abbey Mills
      ...
      Agatha Doe

Pros
Potentially faster average time to find authors
Should be possible to list all authors
Cons
Relies on consistent naming of Authors to make sense to users. e.g. Firstname, Surname or Surname, Firstname

4) Autocomplete Interaction

It should be possible to create an Autocomplete Message Interaction to allow searching for Authors.
Pros
Makes it possible to search for an Author
Cons
This does not seem to be supported by discord.js at this time

Summary

When creating a resource the bot is correctly including the contributor when submitting to AirTable.
This is not happening for the other tables where there is a contributor field.

Existing behaviour

When executing the following commands the contributor is not submitted to AirTable:-

• /add-author
• /add-tag
• /add-category
• /add-blockchain
• /add-glossary

It is also possible to execute these commands without being listed as a contributor.

Expected behaviour

When executing the commands listed above the bot should check if the user is a contributor and ask them to add themselves before trying again.

Once the user executes the commands and is found in the contributor table they should be able to complete the commands as usual and they should be added to the relevant column when storing the new information.

Each of the tables updated by the commands listed above have a Contributor column, which is a reference to the Contributor table.

We currently have a manual process in place for members to be invited to our GitHub Org.

I'd like to automate this by adding a command to the bot, perhaps /github-invite <github-username> or something along those lines.

We'd need to research how to authenticate that the user is who they say they are so that members can't invite just anyone to the org.