| Age | Commit message (Collapse) | Author | 
|---|
|  | I had disabled this for testing, and also only operated on the first
issue in the list for the same reason. | 
|  |  | 
|  | Found this variable in the UIOP docs. Haven't tested it yet, but this is
an idea to not enter the Lisp interpreter when an unhandled error is
triggered.
I wonder if we can conditionally only enable this in a release build. | 
|  | Remove the config test and actually run the program when (main) is
called. | 
|  | Update our idea sketch to reflect the current implementation. | 
|  |  | 
|  |  | 
|  |  | 
|  |  | 
|  |  | 
|  | * Fix quoting and bolding
* Adjust wording
* Add short form of the `--verbose` flag | 
|  |  | 
|  | I had copy-pasted this code from Extreload. Print the actual project's
version. | 
|  |  | 
|  | Makes it more convenient to inspect the config object's fields. | 
|  |  | 
|  |  | 
|  | These options were defined incorrectly as flags, and didn't take
arguments. | 
|  | I forgot the condition that only errors when the required arguments are
missing. | 
|  |  | 
|  | It took a few tries to get this working, but it correctly checks for
these missing arguments now and prints a warning indicating which ones
are missing. | 
|  | * Define command line options for the program
* Define Make rules to build a binary
* Fix system entrypoint definition
* Comment out some application code to test command line option parsing | 
|  | It seems this is the same as before, but it makes it clearer what
symbols come from ASDF.
I had changed the file to use (in-package :asdf-user)` before when I was
trying to add the "lib/" directory to the source registry to try and see
if that made a difference for that problem. | 
|  |  | 
|  | Don't print any output by default. | 
|  |  | 
|  | We don't need to get the output of the executed mail sender program. I
added it for testing purposes. | 
|  | Allow a "sendmail" program to be configured. If set, `deliver-email`
will spawn the program and write the email its standard input.
We can thus send the email by invoking the external program. | 
|  | Include a selection of metadata values in the email.
I needed to pass `config` to `deliver-email` in order to be able to
build a URL to the ticket based on the `endpoint` field.
Also needed to make the field list a vector instead of a list, otherwise
'jzon' interpreted it as being a plist and serialized it to a JSON
object. | 
|  | Take a recipient email address. Build an email containing the issue
details.
Change the `run` loop to only operate on a single issue for testing
purposes. | 
|  |  | 
|  | The Atlassian API documentation for Jira Cloud describes the difference
between version 2 and version 3:
> This documentation is for version 3 of the Jira Cloud platform REST
> API, which is the latest version but is in beta. Version 2 and version
> 3 of the API offer the same collection of operations. However, version
> 3 provides support for the Atlassian Document Format (ADF) in:
>
> * body in comments, including where comments are used in issue, issue
>   link, and transition resources.
> * comment in worklogs.
> * description and environment fields in issues.
> * textarea type custom fields (multi-line text fields) in issues.
>   Single line custom fields (textfield) accept a string and don't handle
>   Atlassian Document Format content.
>
> However, these new features are under development and may change.
https://developer.atlassian.com/cloud/jira/platform/rest/v3/intro/#version
The Atlassian Document Format referenced is described in JSON. Here is
an excerpt of an issue description in the format:
    "description": {
      "version": 1,
      "type": "doc",
      "content": [
        {
          "type": "heading",
          "attrs": {
            "level": 2
          },
          "content": [
            {
              "type": "text",
              "text": "Context"
            }
          ]
        },
        {
          "type": "paragraph",
          "content": [
            {
              "type": "text",
That format would make it much harder to get an issue's description text
for easy inclusion in an email. Fortunately, we can switch to version 2
of the Cloud API with no loss of functionality, and get a plain text
description suitable for inclusion in an email message. | 
|  | Include the fields we need to create an email notification for
newly-created issues. | 
|  |  | 
|  |  | 
|  | Use `startAt` to get fresh pages of results. | 
|  | Need to set the `startAt` field when making the request. | 
|  | Move the loop outside this function. Makes more sense to have it in
`run`, which is doing the pagination etc. This function can worry about
watching a single issue. | 
|  | For each page of issues, watch those issues. Watcher code needs to be
implemented. | 
|  | This should make it easier to test with real values by passing in a
single config object. | 
|  |  | 
|  | We can later make a config from command line arguments.
Also don't require "https://" prefix from endpoint config. Doesn't make
sense to require that in the input when we can add it in the program. | 
|  |  | 
|  | This needs to be configurable as it will be different for each
organisation. | 
|  | Instead of POSTing a string literal, define it with an alist and use
'jzon' to convert it to JSON. | 
|  | Remove old test code. | 
|  | Parse the Jira response into a hash that we can interact with.
Needed to do some finagling to get my "lib" submodule directory to be
searched for systems. | 
|  | Include as a submodule since the library is not in Quicklisp. | 
|  |  | 
|  |  |