| Age | Commit message (Collapse) | Author |
|---|
|
I think this is confusing Homebrew.
|
|
Install to directories instead of filenames. We don't need the
filenames, and on top of that, `$(MAN_PAGE)` was wrong, as it includes
the "doc/" prefix.
|
|
I'm getting a destroot error in MacPorts:
Failed to activate wajir: Image error: /bin already exists and does
not belong to a registered port.
Trying to see if this fixes it.
|
|
Create the man page directory before installing it. Otherwise it fails
to install.
Also use 644 permissions on the man page as that's more appropriate.
|
|
`DESTDIR` seems to be more standardised.
Didn't set the variable because according to the Make manual, you're not
supposed to:
> You should not set the value of DESTDIR in your Makefile at all
https://www.gnu.org/software/make/manual/make.html#DESTDIR_003a-Support-for-Staged-Installs
|
|
Put all files in the tarball in a `wajir_$(VERSION)` folder. Otherwise,
MacPorts couldn't figure out where the root directory was.
|
|
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.
|
|
Since :com.inuoe.jzon is a local dependency, its dependencies weren't
being added to the bundle. Include them as well.
We don't need to add a line for :sysexits as it doesn't have any
dependencies.
|
|
|
|
This seemed to cause the `bundle` target to be run even in the packaged
release tarball. In that case, the 'bundle/' directory should already
exist, and we don't want to rebuild it.
We might also have been able to resolve this by generating the 'bundle/'
tar before the project `git archive` tar, but I couldn't figure out how
to concatenate two tars together with BSD tar.
|
|
Packages source files including dependencies for release.
|
|
|
|
Since I can't load Quicklisp dependencies when building with Homebrew or
MacPorts, do `(ql:bundle-systems)` to create a bundle that includes all
dependencies and can be packaged into a tarball for building from
package managers.
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
* 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.
|
