| Age | Commit message (Collapse) | Author |
|---|
|
Add a few types to collect properties of a message, including message
body, channel posted to, and sender.
Need something like this for the GitHub Commit plugin, where we need
access to the message to get the SHA, and we need the channel to get the
repo URL from the database.
|
|
And add comments and sections.
|
|
Remove these migrations that I had written before installing
'dbmigrations'. These have been replaced by the one defined in
70b3605a346b746273a79c1a3ff4bc40ae0218bf.
|
|
A table that maps channel names with repo URLs in order to be able to
build a commit URL. Previously committed in
d1bdc16c9b1ad9a2b17b90a998640ebad1c02f9a, but now using the
'dbmigrations' format.
|
|
Provide the `moo` command with the proper configuration needed in order
to run.
|
|
Use this for database migrations. Seems to be the right tool for
database migrations in Haskell. Originally I had thought about doing it
manually with 'up' and 'down' SQL files and some kind of Makefile or
script to run them, but then realised that, of course, you have to keep
track of which migration you're on, and figured, well, might want to
outsource that to another program.
I had originally written my migration in Mark Bates' pop/soda format,
but will have to convert that for 'dbmigrations'.
Thankfully got a little help from
https://github.com/basti1302/elm-lang-de#development-setup
on how to actually install the 'dbmigrations-sqlite' package using
Stack. Put the installation command into a new "setup.sh" file to make
it easily repeatable.
Needed to add a bunch of lines to the `extra-deps` section of
"stack.yaml" in order to be able to properly install the package.
|
|
Create a table to store mappings between channels and repo URLs.
We don't have any database configuration set up or anything to run the
migrations yet, but this gets the schema defined.
|
|
Write some short documentation above the function definitions to remind
myself later about what they're supposed to do.
|
|
Extract the GitHub commit plugin code from "Plugin.hs" into its own
module. Now that we have things more set up and working to a certain
degree, we can split the code out.
|
|
Move our base plugin types to a new module to enable us to use them in
both the plugin matching code (which we'll leave in "Plugin.hs") and in
specialised plugin modules.
This enables us to import and provide a list of plugins in `plugins` in
"Plugin.hs" and use these types in that file and in the plugin files
without any circular/recursive module dependencies.
|
|
Instead of implicitly using `String -> String` as the type for plugin
action/perform functions, create a real type to represent this.
|
|
I didn't even need the `matchPlugin` that took `plugins` as an argument,
I can just use the `plugins` function directly in `matchPlugin`. Get rid
of `realMatchPlugin` because that was just a temporary name until I got
things working.
Move `firstPlugin` into the definition of `matchPlugin` because it's not
needed anywhere else and is just used to pattern match for the first
matched plugin in the list.
|
|
I had been using the regex instead of the match result. Do another regex
match to correctly output our SHA instead of the match regex.
I had tried putting the `=~` match in another function and using it from
here and in the list comprehension in `matchPlugins`, but then found out
that, of course, the return types didn't agree (`matchPlugins` needs a
`Bool` and `performPlugin` needs a `String`). Ended up dispensing with
the extra function and doing the match both times instead.
|
|
Take our initial experiment on the regex matcher from before and expand
it into the beginnings of a plugin architecture.
Add a new `Plugin` module. This exports a `Plugin` data type that
collects a regex and a function together. The idea will be to create a
list of plugins, and chat messages will get matched against the regexes
in that list. If the regex matches, the associated function will be run.
If the function produces output, that output should eventually be sent
back to the chat as a message.
Implemented `Show` on `Plugin` manually because the `String -> String`
function can't be derived. Decided to forego that part in the output and
only show the regex when printing.
Ended up with a little redundancy here in the functions for matching
plugins. The `realMatchPlugin` function needs to be renamed, just called
it that for now because I had started with `matchPlugin`, and only later
realised that its interface wasn't what I needed when calling it from
the `Lib` module.
Need to add some doc comments, but figured I'd commit what I have now
since it sort of works.
The `firstPlugin` function is only used by `matchPlugin`, so now I
realise it should probably be a local `where`-defined function.
Also thought the `String -> String` wasn't very descriptive. We'll want
to make a type alias for that that tells people this is a plugin
function.
Added a test plugin inline in this file for now. Eventually our plugins
should be stored in separate files in a "Plugins" directory (or
"Plugin", depending on how the module system works, will have to look
into that). For now, the program outputs the correct string created by
`gitHubCommitAction`, which is actually pretty cool. It's not actually
the really correct string, as the `match` variable is the regex instead
of the matched part of the test string, but close enough for now. We'll
go back and correct that momentarily.
Needed to add `Plugin` to the `exposed-modules` section in the `library`
build metadata in order to properly build the code. Was getting this
error about it:
Warning: The following modules should be added to exposed-modules or other-modules in /Users/tw/Documents/Development/sorbot/sorbot/sorbot.cabal:
- In the library component:
Plugin
Missing modules in the cabal file are likely to cause undefined reference errors from the linker, along with other problems.
Really liking this so far!
|
|
Only match SHAs if they're the full 40 characters long. This will become
important later when we have an actual chat bot and we don't want to
match on partial SHAs.
|
|
* Add the 'regex-tdfa' library for RegEx handling
* Experiment with matching a Git SHA
|
|
Apparently you can't write in any old string into the license field, so
my SPDX-formatted license caused the build to fail.
It was a bit difficult as a complete beginner to figure out how I was
supposed to format the version given the `(Maybe Version)` in the
documentation:
https://www.haskell.org/cabal/release/cabal-latest/doc/API/Cabal/Distribution-License.html#t:License
but fortunately a search through some open source Cabal files on GitHub
revealed the answer. Disappointing, though, that I can't declare the `+`
part of the license in an officially supported capacity, but okay.
|
|
|
|
$ stack new sorbot new-template
GHC v8.0.2
|
