Age | Commit message (Collapse) | Author |
|
When I tried building with Homebrew, I got this error:
$ wajir --version
error: Failed to find the WRITE-DATE of
/private/tmp/wajir-20220522-65276-i3kj2/bundle/local-projects/:
No such file or directory
Try and pre-compile the program version to counter this error.
|
|
|
|
Re-enable the main run code.
|
|
Use `with-user-abort` to exit on a Control-c SIGINT.
Used the following tutorial for inspiration:
https://stevelosh.com/blog/2021/03/small-common-lisp-cli-programs/#s12-errors
Apparently Control-c should exit with code 130 according to this:
https://tldp.org/LDP/abs/html/exitcodes.html
Followed these Stack Overflow answers to turn off the interactive
debugger in an implementation independent way:
https://stackoverflow.com/questions/3074586/how-to-turn-off-the-debugger-in-sbcl/3074698#3074698
https://stackoverflow.com/questions/69280179/unmatched-close-parenthesis-when-sbcl-debugger-is-turned-off
This still opens the interactive debugger if Control-c is pressed before
`(main)` is called, but I don't know if there's any way to prevent that.
|
|
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.
|
|
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
|
|
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.
|
|
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.
|
|
|
|
Set up a Common Lisp project skeleton and make a request to the
Atlassian API to get a filtered list of issues that the current user
isn't watching.
|