ubclaunchpad / rocket2

🚀 The official UBC Launch Pad Slack bot and team management platform

Rocket 2

Rocket 2 is the official UBC Launch Pad Slack bot and team management platform.

Rocket 2 is a from-the-ground-up rewrite of the original Rocket, and it is a Slack bot that aims to be a ChatOps-style tool for team management across platforms like GitHub and Google Drive, with extensive configuration options so that it can be used by other organizations as well. Rocket 2 is used, built, and maintained with ❤️ by UBC Launch Pad, UBC's student-run software engineering club.

	Main features
💬	Unix-style command system in Slack - invoke commands with a simple /rocket in Slack
🔗	Platform integrations - easily configure GitHub organization invites and teams, Google Drive permissions, and more
🗂	Team directory - provide and manage member information such as emails and other accounts
🔒	Permissions system - control access to Rocket functionality with a tiered set of permissions
🔨	Hackable and extensible - an open codebase makes it easy to add commands, scheduled modules, and more!

📦 Usage

Check out our command reference pages to get started interacting with Rocket, or take a look at how Rocket is used at UBC Launch Pad in the Launch Pad handbook.

To set up a Rocket instance for your organization, refer to the deployment and configuration documentation.

📚 Contributing

Any contribution (pull requests, feedback, bug reports, ideas, etc.) is welcome!

Please refer to our contribution guide for contribution guidelines as well as detailed guides to help you get started with Rocket 2's codebase.

rocket2's Issues

Implement slack events adapter

Use the slack events adapter from the slackeventsapi to call the app mention handler in core.py when listening to the appropriate event.

Create permissions model

In model/permissions.py, create a permissions model - this might be a Permissions class but might also be something else. We should have at least three permissions levels:

• Admin
• Team lead
• Member

DBFacade missing delete_user and delete_team methods

Methods that are in DDB class but not in the Facade class need to be added

Create Slack client

In bot/bot.py (or a similar file) create a new Slack client per the Python Slack library. In particular it should connect to the Slack bot created in #1 - for now this can be hardcoded but eventually we will want it to be configurable.

Create pre-commit hook

Travis is protecting our main branches but it’s not officially documented what our build is doing, nor is it very convenient to run all those commands locally. So, we should add a build script to run all those commands and have contributors add this as a pre-commit hook, so that we don’t have to run a Travis build to find linting errors.

Setup Slack events

After the Slack events adapter is implemented in #71, we need to set it up to actually receive Slack events, per the instructions in the "Development workflow" section of the Python Slack Events Adapter.

Organization PR stats, prize draws

PR stats per person:

• number of reviews
• number of PRs
• turnaround time?
• example: https://pullreminders.com/installs/12406312/leaderboard?dates=30d&view=reviews

Prize draws:

• weighted by a metric (# of PRs, # of reviews, etc.)
• ability to exclude team leads
• send winner's name to #general on defined intervals, with lots of emoji

Implement Slack client "send message" methods

Design and implement methods in the Slack client class from #26 so that other modules can send direct messages to a user or send a message to a channel.

Handling errors at the core level

Currently core.py returns 0, 1, or -1 depending on whether or not a command follows a valid format, the command is successful, or the command results in an error. This should be changed so that error handling is done rather than returning a value that indicates an error took place.

Auto-deploy python documentation

Would be nice if we had documentation automatically deployed onto Read the Docs. More specifically, the API docs on database, commands, and maybe a short little tutorial on how everything works together, and how to build a plugin.

Might need some way to access through ubclaunchpad (since this repo is under the organization).

Implement concurrent request handling

The Slack Python SDK may not concurrently handle events. If that's the case, we'll want to make some of our own request handling (e.g. the event handler from #29) concurrent, probably using the asyncio standard library module.

Team storing isn't validated

It doesn't give any feedback on if the team is stored correctly or not. It should return true if the team is stored successfully, and false if it isn't.

Research metaclasses for commands framework

It looks like we'll want to use metaclasses to enforce an interface for the commands framework and possibly create the commands on launch. We should research this more.

Create script for configuring aws for travis test

A nice script with heredocs/strings. Blocked by #33.

tiered permission model

The current Rocket only has admins and everyone else - it's probably more flexible to have an additional lead position that has permissions like team and repo creation. Something like:

• admin: create, delete, read
• lead: create, read
• everyone else: read

Start documentation

Create a docs/ directory containing our MVP etc. Also create a README and a LICENSE.

Create initial `team` command documentation

Create a document in docs/ (similar to the one created for #25) that lists the various options/help strings/etc that we will implement for MVP for the @rocket team command.

In particular, we will want to match the functionality of the current @rocket edit-team, @rocket remove-user, @rocket view-team, @rocket add-team, @rocket add-user, @rocket remove-team, and @rocket teams commands (but hopefully with better/more consistent names!). These should probably all be implemented as subcommands to the core @rocket team command (similar to how user commands are being done).

Ability to query logs by sending commands to Rocket

Setup Travis

Setup Travis CI to run on each push/pull request. At the very least it should:

• Run automated tests.
• Run pycodestyle to ensure code style adherence.
• Push code coverage statistics to Codecov.io (look into coverage.py).

Create initial documentation `user` command

Create a document in docs/ that lists the various options/help strings/etc that we will implement for MVP for the @rocket user command.

In particular, we will want to match the functionality of the current @rocket remove-user, @rocket view-user, @rocket edit, @rocket set, and @rocket add-user commands (but hopefully with better names!). These should probably all be implemented as subcommands or flags to the core @rocket user command.

Setup logging

After deployment we'll want to set up some logging. In particular we will want logging levels as well as a general facade structure (so that for instance we can use a local log file or AWS CloudWatch Logs in the future). These should be provided by the logging standard library module - see also the logging tutorial and tips on Hitchhiker's Guide.

Setup Slack manual testing

Create a new bot on Slack and a channel to test it on (a good name for this would be #rocket-test) so that we can try out our bot "live" without interrupting the old Rocket.

Create database facade

Create a database facade (probably in a database/ directory) that exposes core database actions that commands/events can interact with. For now, focus on user-related actions; these can just be stubbed out, since the point of this ticket is more to get the database facade's API up and going so other modules can start calling it.

This doesn't necessarily have to be a whole class; it might be better to leave it as a set of functions (but I leave that up to the developers!).

Stub out `user` command

Create a user command class in command/commands/, stub out its main methods (e.g. handle()), and implement help() and name().

Add SlackEvent to data model

Add a SlackEvent class to model/ to represent a Slack event parsed from JSON. In particular, it should have (de)serialization functions (to convert to and from JSON). It may also be helpful to have "sub data types;" for instance an enum for the possible event types (or at least the ones relevant to Rocket 2.0's MVP).

Create data model for users

In model/user.py, create a class User that we'll use to represent users. At the moment in Rocket users have:

• Name
• Email
• Position
• GitHub username
• Major
• Bio

In the future we will also need to add permissions in the future and potentially other fields, so it should be somewhat extensible.

Research pytest and different types of tests (if possible)

Have pytest run database tests only when travis is running the tests (full tests). If the user doesn't have the database running (by pinging localhost:8000), we just give a warning, saying that the database isn't running, or have a whole different group of tests (unit tests vs functional tests).

Server crashes with NameError on launch

SLACK_SIGNING_SECRET is undefined, it should be read in from an environment variable.

File "/Users/rwblickhan/Developer/rocket2.0/server/server.py", line 16, in <module>
    slack_events_adapter = SlackEventAdapter(SLACK_SIGNING_SECRET,
NameError: name 'SLACK_SIGNING_SECRET' is not defined
[2018-11-10 15:44:14 -0800] [715] [INFO] Worker exiting (pid: 715)

Implement model equality

Just as a convenience function (so that we don't have to do user.get_slack_id() == user2.get_slack_id() and user.get_biography() == user2.get_biography() every single time).

Setup containerization

Rocket 2.0 should be containerized and this needs to be set up.

Implement `user` command parsing

In the handle() command created in #31, implement argument parsing with argparse. This should be based on the documentation created in #25.

Setup unit tests

Create a sample test in tests/ and ensure it runs - in particular this test should be automated in Travis builds (see #2).

Create data model for teams

In model/team.py, create a class Team that we'll use to represent teams. At the moment in Rocket teams have:

• Display name
• Platform
• List of members
• GitHub team name

In particular we will need to decide how to represent the list of members internally - potentially it could be a list of User objects (see #3), some kind of identifier that could be referenced externally, or something else.

Look into forking pymarkdownlint

We're using mdl to lint Markdown (e.g. for documentation). This is rather inconvenient because it's written in Ruby but everything else is in Python 3. We tried using the (unmaintained) pymarkdownlint instead but it appears to be written in Python 2. We should investigate how easy it would be to convert this to Python 3 - if it would be relatively straightforward we should fork it and replace mdl.

Enforce documentation standards

Everything should be documented with Python docstrings. Checking for docstring style should be part of our CI pipeline; luckily there's a tool called pydocstyle for just this purpose.

No error checking in dynamodb user commands

We don't check that the user is valid (slack_id exists). Please do so.

Implement `team` command parsing

In the handle() command created in #51, implement argument parsing with argparse. This should be based on the documentation created in #50.

Start DynamoDb connection class

Create a class to encapsulate a connection to DynamoDb, using the boto3 library. This will eventually be called from the database facade created in #30. For now it's probably enough to stub out some of the major methods, and possibly start methods to convert instances of our data model into DynamoDb equivalents.

Add __str__ to data model classes

For the purposes of logging/debugging it would be useful to add a __str__() special method for each data model class that prints out the data that it contains.

Add event handler method

Add a core.py (or some other reasonable name) to a command/ directory (or some other reasonable name) that will expose an event handler method that will be sent the event JSON strings from the Slack client. For now it just has to accept these and deserialize them to into SlackEvent objects (as implemented in #28).

Missing getter/setter for User.name

Kinda weird that nobody noticed. While testing the User class with the .__dict__, which prints out all class attributes, I found that there is a name attribute, but no getters or setters. Needs to be fixed quickly.

Add slack_event handler for when user joins Slack and add User create handler

Add functionality such that a user is created and store to database when they first join Slack

Create Slack client class

Encapsulate the Slack client connection from #7 in a class for further extension.

Handle default command parsing for command classes

Currently, if a command such as @rocket user is handled without any subparsers, an error is returned. Add a default handler so that handler returns help text.

No error checking in dynamodb team functions

There are no checks for dynamodb team existance (undefined). Please do so.

The best way would be to raise a LookupError with some proper text explaining what happened to the poor user.

Stub out `team` command

Create a team command class in command/commands/, stub out its main methods (e.g. handle()), and implement help() and name() (double check with the implementation of the user command as implemented in #31).

Setup deployment/continuous delivery

Set up the very basics of deployment, probably with AWS EC2/DynamoDb, so that we can begin deploying after every pull request.

Add type annotations to data model

Once our data model starts stabilizing a bit more, we should add type annotations from the typing standard library module and add type checking to our Travis builds.

Start implementation of `user` Commands with database

Create basic implementation between user commands and database for user edit, view, and delete commands

Feature random channels

Feature request: every week, feature a random public channel to help with channel discovery (for example, #rock-it-beats or #interview-prep)