Skip to content

Milestones

List view

  • Other platforms.

    Towards working on other platforms such as: Raspberry Pi 4b Ubuntu Server (without GUI) MacOS Windows.

    No due date
    •0/1 issues closed
    0% complete1 open0 closed

  • Next

    #127 Check when GitHub repo is pushed to GitLab correctly. #124 Make sure the "run CI on repo" works completely. #128 Copy complete repo in one go.

    No due date
    0% complete0 open0 closed

  • Restore tests.

    Ensures the tests pass.

    No due date
    •0/1 issues closed
    0% complete1 open0 closed

  • Code quality compliance.

    Improve Google Shell Style Guide Compliance.

    No due date
    •1/2 issues closed
    50% complete1 open1 closed

  • Run over tor.

    Make it automatically run over tor.

    No due date
    •0/5 issues closed
    0% complete5 open0 closed

  • papercuts

    Eliminates small things that may annoy the user, for example, if a timeout occurs in the CI runner, the build status is currently not set. Ensure it is set to Pending such that the user can see that it was a timeout (after a while).

    No due date
    •1/2 issues closed
    50% complete1 open1 closed

  • More simplified user configurations

    Gives the user more options to easily change the behaviour of the repo. For example, allows the user to prevent the GitLab server from running at boot with a single boolean, stop the CI with a single boolean etc.

    No due date
    •1/11 issues closed
    9% complete10 open1 closed

  • Improve verbosity

    No due date
    •0/2 issues closed
    0% complete2 open0 closed

  • Reduce boiler plate code (browser controller).

    To realise 100% automation: - the GitHub personal access token is set using a browser controller. - the GitHub SSH deploy key is set using a browser controller. - the GitLab runner token is retrieved using a browser controller. See which of these actions can be realised through an API or for GitLab, through the local docker.

    No due date
    •0/1 issues closed
    0% complete1 open0 closed

  • Efficiency

    No actions are taken if they are not necessary. Currently everything brute-force removes everything and re-installs/enables it. That makes the repo slower than it needs to be. Examples are: - [ ] Setting the GitHub personal access token. - [ ] Setting the GitHub SSH key. - [ ] Removing and pushing the copy of the GitHub repository from GitHub to GitLab for each separate commit, instead preserving the repository in GitLab and pushing the changes per commit. ... etc.

    No due date
    •1/5 issues closed
    20% complete4 open1 closed

  • Verify GitLab server and runner (un)installation works.

    Verifies the GitLab installation, removal and re-installation work consistently. Also ensures the GitLab runners work after installation, removal and re-installation.

    No due date
    •3/8 issues closed
    37% complete5 open3 closed

  • Automatically runs in background upon boot

    Sets up a boot script/cronjob that continuously monitors your GitHub user accounts (also after rebooting your machine/device) and automatically triggers new CI builds on new commits in the repositories of the GitHub user accounts.

    Overdue by 2 year(s)
    •
    Due by February 1, 2023
    •6/6 issues closed
    100% complete0 open6 closed

  • Make it practically usable for others.

    Automatically sets the commit build status (instead of only pushing the build status and build status icon to a GitHub repository.

    Overdue by 2 year(s)
    •
    Due by April 2, 2023
    •2/4 issues closed
    50% complete2 open2 closed