Feature overview Webhooks on a per namespace basis. These would be triggered on events that would be of interest to the namespace owner, primarily on the status of builds that are submitted.

Problem space Adding webhooks would allow users to help integrate Djinn CI with their development flow, and help kick off things on their end when builds are submitted/completed.

Additional context --

Feature overview Builds that are submitted to a namespace via a push or pull-request should be automatically tagged with the ref. This ref would be the ref of the repo a commit was pushed to, or the ref of the target repo in a pull-request.

Problem space It can be handy to organize builds by the branches they were triggered from. Whilst Djinn CI has no concept of tying a build to an individual repo, you can instead tag the builds to categorize them, this however is arduous.

Additional context This should perhaps be an optional thing that is configured during namespace creation.

Version devel +5e91bbe Mon Apr 26 18:47:15 2021 +0100

Environment Hosted

Describe the bug Right now, if we deploy a new version of the djinn-worker (which would involve a restart) whilst builds are running this results in builds being re-run. Whilst this isn't exactly a bad thing we want this to be more graceful. Ideally the following should happen when a worker picks up on a build that is being re run:

• Mark the build as orphaned, or as an automatic re-run
• Clear down the previous information it has stored on the build (timings, job output, artifact information)
• Re-run the build as if it were clean

Reproduction steps Run a build, then restart the djinn-worker.

Screenshots --

Logs --

Additional context --

Version devel +c65c3f5 Sat Apr 24 16:37:30 2021 +0100

Environment Hosted

Describe the bug The make.1 stage in the manifest for building Djinn is failing due to the test Test_TagStoreCreate. This has failed twice so far, but passed every other time. This appears to be happening sporadically, needs further investigation.

Reproduction steps Hard to reproduce due to the sporadic nature.

Logs See the below snippet from the build output,

+ cd djinn
+ ./make.sh
go: downloading github.com/DATA-DOG/go-sqlmock v1.5.0
--- FAIL: Test_TagStoreCreate (0.00s)
    tag_test.go:120: build.(*TagStore).Create - build/tag.go:189: database.Store.Create - database/database.go:451: Query 'INSERT INTO build_tags (build_id, name, user_id) VALUES ($1, $2, $3) RETURNING id', arguments do not match: argument 0 expected [int64 - 3] does not match actual [int64 - 10]
FAIL

Additional context The builds have been tagged as flaky, and can be seen here: https://djinn-ci.com/n/djinn-ci/djinn?tag=flaky, also listed below:

• https://djinn-ci.com/b/djinn-ci/5
• https://djinn-ci.com/b/djinn-ci/7

Feature overview

A masked variable would be one that is not displayed in the output of build logs, and instead masked over with a string such as xxxxxx.

Problem space

Some builds may want to make use of API tokens to make a callout to a third-party API during a run. As of now, they can do this by setting these tokens as a variable in either a build manifest, or via the UI, however these secrets would not be protected, and would be displayed in the build logs. It is correct that a user submitting a build could take additional steps to reduce the output of sensitive tokens in the build logs, but it would beneficial if the platform aided here too.

Additional context

Variable masking should be supported when creating a variable for use in a build via the UI. When a variable is masked it should be encrypted on the backend, and replaced with a string such as xxxxxx in build logs. Variables that are masked should be of a certain minimum length, this way we can ensure that we don't superfluously strip information from build logs when masking. Once a variable has been masked, its value cannot be viewed by the API, and only be viewed via the UI by the creator of said variable with password verification

Feature overview During custom image creation, there should be an option to download an image via FTP, whereby you specify an FTP URL for Djinn CI to download the image from.

Problem space QEMU images can be large, this causes upload times to be incredibly long and is further constrained by the user's bandwidth. This doesn't lead to a very pleasurable UX when uploading a custom image whereby you have to sit there for a few minutes before moving on. Allowing the image to be downloaded via an FTP site would allow for this to happen in the background.

Additional context There should be a sensible timeout for downloading these files, perhaps something like 15 minutes.

This adds the ability to configure webhooks on a per-namespace basis. As of now the following events are emitted,

• build_submitted
• build_started
• build_finished
• build_tagged
• collaborator_joined
• cron
• images
• objects
• variables
• ssh_keys

this includes changes to the necessary user and API documentation too.

Feature overview

The integration tests should be expanded to better capture some of the flows a user would experience whilst using the Djinn CI platform.

Problem space

The current integration tests are fine, but could be better expanded. We should try and construct flows of requests that better represent a user's journey through the platform.

Additional context

--

Feature overview Namespaces should provide a URL that would generate an SVG badge of the latest build submitted to that namespace. This would simply display the build's current status. The URL should look something like /n/<username>/<namespace>/-/latest.svg.

Problem space This would allow for the badge to be embedded into the readmes of projects that use Djinn.

Additional context Literally every other CI platform has this.

Version djinn devel +b2456a5 Sat Apr 24 16:50:25 2021 +0100 linux/amd64

Environment --

Describe the bug Segfault happens when you run the offline runner with an empty driver.conf file,

[main][~/code/djinn-ci/djinn]$ cat ~/.config/djinn/driver.conf
[main][~/code/djinn-ci/djinn]$ djinn
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x20 pc=0xa0f214]

goroutine 1 [running]:
main.main()
    /home/andrew/code/djinn-ci/djinn/cmd/djinn/main.go:202 +0x11b4

this should instead just throw up an error complaining about no drivers having been configured.

Reproduction steps Create an empty driver.conf file and run djinn.