danth / flakeaway Goto Github PK

Description

• Users should be able to configure Cachix per-repository
• Then, everything built for that repository will be pushed to the corresponding cache
• A link to the cache will appear in status messages

Use case

Users can already run a cache on the Flakeaway server directly, however some may prefer to use this separately hosted option to reduce load.

Description

Support a configuration file within each repository which globs for flake outputs to include or exclude.

Use case

• Allows problematic outputs to be disabled
• Allows Flakeaway to be used only for running checks

Flakeaway should create a garbage collection root for the latest build of each output.

This allows building to be switched off without new commits being missed.

Helps with #4

Current behaviour

If an output has a / character in its name, its garbage collection root ends up in a subdirectory.

Expected behaviour

The / should be removed, or replaced with a different character.

Additional context

No response

Description

Flakeaway should offer the ability to automatically update flake.lock at a configurable interval.

Advantages

Keeps the flake inputs up-to-date without it having to be done manually.

Implementation details

• The interval should default to around once per week.
• Changes must be made via a pull request to avoid breaking the main branch.
  • The pull request may be merged automatically once checks (including checks by other apps) pass.
    • This may be implemented using GitHub's auto-merge feature.
  • Pull requests should merged using the rebase strategy to reduce unnecessary merge commits.
  • Flakeaway must not have more than one PR open at any given time.
    • If a pull request remains open until the next interval, it should either be updated via a force-push, or closed and a new one opened.

Description

Build failures caused by the builder not having enough RAM should be detected and reported with a different message.

Advantages

Allows the user to know why the build is failing, when it works locally.

Implementation details

No response

If a branch is not a valid filename, its name is sanitized and outputs are stored under the sanitized name instead.

Later, those outputs can be deleted because a branch does not exist with the sanitized name.

Possible solutions:

• Sanitize the list of existing branches
• Hash or base64-encode branch names rather than sanitizing them

Current behaviour

If an evaluation uses an import-from-derivation which requires an unsupported system, the job is no longer marked as skipped.

Expected behaviour

The evaluation should be skipped rather than fail.

System information

No response

Log output

No response

In the case of a build failure, determine which derivation failed and publish the log for that one.
Otherwise, publish the log for the toplevel derivation.

Jobs should be paused if there is not much disk space on the server. Perhaps add a job to run the garbage collector.

As a minimum, evaluations should run before builds.

Use priorityQueue.

Old garbage collection roots should be removed when a newer commit builds successfully, and when the branch is deleted.