c8h4/aux-search
1
0
Fork 0
Code Issues Pull requests Packages Releases Activity
Search auxolotl packages and options. Forked from https://github.com/nixos/nixos-search
15 commits 3 branches 0 tags 1.5 MiB
Elm 48.9%
Rust 32.4%
SCSS 8.4%
Nix 6.6%
JavaScript 2.2%
Other 1.5%
Go to file
Rok Garbas 99eae108c7
search on page load and on second search query, fixes #5 (#8)
2020-05-08 23:59:14 +02:00
.github/workflows Remove hourly build (#2) 2020-04-11 04:05:54 +02:00
scripts somehow in a working starte with bugs and missing features 2020-05-08 15:24:58 +02:00
src search on page load and on second search query, fixes #5 (#8) 2020-05-08 23:59:14 +02:00
tests intial version of elm+webpack setup 2020-03-28 05:09:01 +01:00
.gitignore add yarn.lock and direnv integration 2020-03-30 11:00:04 +02:00
default.nix add some integration packages 2020-03-30 09:27:22 +02:00
elm.json make a request to elasticsearch, nothing fancy 2020-04-07 07:05:50 +02:00
package.json intial version of elm+webpack setup 2020-03-28 05:09:01 +01:00
README.md init readme (#3) 2020-04-21 23:55:39 +02:00
webpack.config.js intial version of elm+webpack setup 2020-03-28 05:09:01 +01:00
yarn.lock add yarn.lock and direnv integration 2020-03-30 11:00:04 +02:00

README.md

search.nixos.org

This repository contains the scripts and the web application for search.nixos.org.

How this project came to be

Initial idea was to replace NixOS packages and options search which was fetching one JSON file which contained all packages (or options). This approach is good for its simple setup, but started to show its problems when packages number was getting bigger and bigger. I'm sure we could optimize it further, but ideas what all could we do if there would be some database in the back were to tempting not to try.

For backend we are using Elasticsearch instance which is kindly sponsored by bonsai.io. On the frontend we are using Elm.

Ideas we want to explore

Apart from searching packages and options we would like to:

  • Not only search for latest channels, but be enable to search in any evaluation. We need to explore how much in the past we can go, I'm sure we will have to make some compromises.
  • Provide each maintainer with a page that lists packages that they maintain. A page - later - could also show his ticket and opened Pull Requests.
  • Each package should have a page which would show versions in different evaluations/channels. It could also show - at one point - ticket that this package
  • With all this information in the database it would be very useful to show some sort of reports. Few examples that come to my mind:
    • What packages and options were added/removed/changed between to evaluations? This could be useful for Release Manager when making release notes or just in general to see difference what has changed since last time.
    • How are we doing with tickets/pull requests? Burn-down chart maybe. The idea behind is to have a nicer view over current status of tickets/pull requests.

Probably there are more ideas I just need to remind myself to write them down.

Development

To start developing open a terminal and run:

$ nix-shell --run "yarn dev"

You can point your browser to http://localhost:3000 and start developing. Any changes to source files (./src) will trigger a hot reload of an application.

Deploying

  • On each commit to master branch a GitHub Action is trigger.
  • GitHub Action then builds production version of the web application using yarn prod command.
  • The built web application (in ./dist) is then deployed to Netlify.
  • GitHub Action can also be triggered via Pull Request, which if Pull Request was created from a non-forked repo's branch, will provide a preview url in a comment.