alajmo / mani

:robot: CLI tool to help you manage repositories

mani

mani is a CLI tool that helps you manage multiple repositories. It's useful when you are working with microservices, multi-project systems, many libraries or just a bunch of repositories and want a central place for pulling all repositories and running commands over them.

You specify repository and commands in a config file and then run the commands over all or a subset of the repositories.

Interested in managing your servers in a similar way? Checkout sake!

Features

• Clone multiple repositories in one command
• Declarative configuration
• Run custom or ad-hoc commands over multiple repositories
• Flexible filtering
• Customizable theme
• Portable, no dependencies
• Supports auto-completion

Table of Contents

• Installation
  • Building From Source
• Usage
  • Create a New Mani Repository
  • Command Examples
  • Documentation
• License

Installation

mani is available on Linux and Mac, with partial support for Windows.

• Binaries are available on the release page

• via cURL (Linux & macOS)

  curl -sfL https://raw.githubusercontent.com/alajmo/mani/main/install.sh | sh

• via Homebrew

  brew tap alajmo/mani
  brew install mani

• via MacPorts

  sudo port install mani

• via Arch (AUR)

  yay -S mani

• via Nix

  nix-env -iA nixos.mani

• via Go

  go get -u github.com/alajmo/mani

Auto-completion is available via mani completion bash|zsh|fish|powershell and man page via mani gen.

Building From Source

1. Clone the repo
2. Build and run the executable

   make build && ./dist/mani

Usage

Create a New Mani Repository

Run the following command inside a directory containing your git repositories:

$ mani init

This will generate two files:

• mani.yaml: contains projects and custom tasks. Any sub-directory that has a .git inside it will be included (add the flag --auto-discovery=false to turn off this feature)
• .gitignore: includes the projects specified in mani.yaml file. To opt out, use mani init --vcs=none.

It can be helpful to initialize the mani repository as a git repository so that anyone can easily download the mani repository and run mani sync to clone all repositories and get the same project setup as you.

Run Some Commands

# List all projects
$ mani list projects

# Count number of files in each project in parallel
$ mani exec --all --output table --parallel 'find . -type f | wc -l'

Documentation

Checkout the following to learn more about mani:

• Examples
• Config
• Commands
• Changelog
• Roadmap
• Project Background
• Contributing

License

The MIT License (MIT)

Copyright (c) 2020-2021 Samir Alajmovic

mani's Issues

Provide a way to add projects.

Is your feature request related to a problem? Please describe

Not a problem, but a missing feature

Describe the solution you'd like

As a mani user, I would like to be able to create new projects without manually modifying the yaml file.

Feature: Add new projects already to an existing mani yaml
    Background:
        Given there is an existing mani repository

    Scenario: Add to an existing mani repository
        Given I have cloned a new project in a subdirectory of the mani repository
        When I run the mani sync projects command
        Then the mani repository is updated with the new project

    Scenario: Use mani cli to check out project
        Given there is a project that I can clone
        When I use the mani clone project command
        Then the mani repository is updated with the cloned project

Additional context

Another related feature is removing a project, I suppose, but I'll leave that for another feature request. I'm purposefully not being prescriptive in the scenario definitions above. I'm not sure what cli commands would fit in best with the existing cli or your way of doing things. Maybe something like: mani sync --projects is an option for the first scenario? That might get confusing with mani sync though. Maybe mani update-projects? Or if there is some use case for many different kinds of updates, then mani update --projects?

The second scenario might be a bit of a stretch, I suppose. mani checkout --github=mikelane/amazing-repo-name might work? That might end up causing you a lot of work, though. I wonder if you could tie into exec... so like mani exec gh repo clone mikelane/amazing-repo-name and then have mani recognize that it needs to update the yaml file?

Add option to omit project output if there is no cmd output

Is your feature request related to a problem? Please describe.
I would like to be able to run a command on my projects, but only show output for the projects where output isn't blank.
For example, given the following task in mani.yaml:

tasks:
  git-status:
    desc: show working tree status
    output: table
    parallel: true
    cmd: git status -s

I get the following output when I run mani run git-status -t main

+----------------+--------------+
| Project        | git-status   |
+----------------+--------------+
| HomeAutomation |              |
+----------------+--------------+
| Linux          | ?? test_file |
+----------------+--------------+
| Vim            |              |
+----------------+--------------+

I don't want to see HomeAutomation and Vim in the output table because cmd didn't return anything. I want to see this:

+----------------+--------------+
| Project        | git-status   |
+----------------+--------------+
| Linux          | ?? test_file |
+----------------+--------------+

Describe the solution you'd like
I think adding an option in the output section would do the trick.
For example, you could call it printempty and it could be true by default. I could set it to false for my purposes.

Additional context
I just tried this tool today and I'm loving it!
I had written my own solution to the same problem a few years ago, but I like yours much better so I think I will switch over.
Keep up the good work :)

Add --tags feature for `mani sync`

Is your feature request related to a problem? Please describe

I only want to sync certain repos on certain machines. Currently, mani sync only has the option to clone my repos.

Describe the solution you'd like

I want to be able to clone a sub-set of my repos, such as: mani sync --tags main

Additional context

The same should probably apply to --paths and --projects as well.

Thanks!

Windows support

Hi there!

Is your feature request related to a problem? Please describe

I was wondering if it is possible to bring to mani to Windows?!

Describe the solution you'd like

An extra Windows installer on each GitHub release.

Additional context

Great project! 🙂

external variables to "mani run" stmt

Is your feature request related to a problem? Please describe.

We separated our main repo in 3 different repo with custom use:

1. Pipeline definition
2. Jobs
3. Tables definitions

Today, we need to move between repos for create a complex process.

 git checkout -b feature/my_new_feature_A
 ... # more git commands - git diff, add, commit, push
 cd ..

cd repo2
git checkout -b feature/my_new_feature_A
... # more git commands  - git diff, add, commit, push
cd ...

cd repo3
git checkout -b feature/my_new_feature_A
... # more git commands  - git diff, add, commit, push
cd ...

That's it the worst case (add a new feature).

I tried to use "env", but we need to use dynamic variables (for branch names... for example).

Describe the solution you'd like

Something like:

in yaml:

    new-branch:
        cmd: git checkout -b ${branch_name}
        env:
            branch_name: $1

mani run new-branch -a feature/my_new_feature_A or something similar.

Additional context
I saw similar projects, but all of them has sync/bulk commands. (see status for every repo, pull changes, see last_commits per repo). In this case, I'm searching for a method to work with multiple repos and manage their life-cycles

Sorry for broken english. Good repo!

Ability to filter projects by target from the command line

Is your feature request related to a problem? Please describe

targets are a useful way to define named groups of projects, for example all projects with a certain set of tags. However, I believe that currently those targets can only be referenced "statically" in the Mani config for a task, to control which projects that task applies to.

It would be useful to be able to select the projects to operate on from the command line when executing mani, referencing the targets defined in the Mani config.

Describe the solution you'd like

In much the same way that mani currently supports selecting the projects to operate on via the --projects, --paths and --tags command line arguments, it could have a --targets option to reference the targets declared in the config and run the specified tasks/commands on those projects, eg when using the run or exec command.

Additional context

A similar case could be made for specs, which are named groups of config that alter task execution and output. It would be handy to have a --spec command line argument for mani, to select which spec to apply.

Possibility to add multiple remotes?

Is your feature request related to a problem? Please describe

Sometimes a user may want to use multiple remotes/push to multiple remotes.

Describe the solution you'd like

One possible solution could be to make the url section of mani.yaml a list/array, or add a new remotes property.
The first entry could be the default remote used for clone.

Updating .git/config could happen through some task that runs git remote add ${remote}, iterating over project/remotes for each respective repo managed by mani.

Additional context

Thank you for this tool as this looks more modern than myrepos!

Mani init fails when CWD is a git repository

• I have the latest version of mani
• I have searched through the existing issues

Info

• OS

  • Linux
  • Mac OS X
  • Windows
  • other

• Shell

  • Bash
  • Zsh
  • Fish
  • Powershell
  • other

• Version:

Version: 0.23.0    
Commit: 83b2ffb   
Date: 2022-12-31T11:24:08Z

Problem / Steps to reproduce

Let's assume test_dir is a dir with a lots of git repos. Let's assume we want test_dir to be a git repository itself, with a nice README.md explaining how to checkout included repos:

cd test_dir
git init .
mani init
error: exit status 1

You can't init many, it returns an error.

Workaround: Move temporarly the .git folder to TMP_GIT, do the mani init and rename TMP_GIT to .git again.

Failing SHA256 checksum in brew install

Trying to install mani via brew and am seeing a SHA256 mismatch.

$ brew install mani
==> Downloading https://github.com/alajmo/mani/releases/download/v0.20.0/mani_0.20.0_darwin_amd64.tar.gz
==> Downloading from https://objects.githubusercontent.com/github-production-release-asset-2e65be/216899950/15be3934-f630-4576-8963-8b3023244775?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAIWNJYAX4CSVEH53A%2F2022
######################################################################## 100.0%
Error: mani: SHA256 mismatch
Expected: b48606dc081be0d78392dba7ce8f1b2332833cc0c2908d5dd314d09f4912b632
  Actual: 91b3faa34cc184fe176292b9be9e2395db4a521f2cafda4db73d659dc3ca4714

Don't block mani operation for existing repos, when a target repo doesn't exist

Is your feature request related to a problem? Please describe

If I run a mani operation and one of the target repos doesn't exist, I get an error as such:

╭─mike@asus ~
╰─➤  mani run git-status --all
error: path `/home/mike/testrepo1` does not exist

Describe the solution you'd like

I would prefer for this to be a warning instead of an error and have the mani operation complete successfully for the repos that do exist.

Additional context

I love mani and all the great work you're doing!

Add a dependsOn option for tasks and projects

Is your feature request related to a problem? Please describe

I like the fact that you can run tasks in parallel. However, to complement this without running into issues a dependsOn option can be used to sort tasks and projects to make sure they only run when their parents have been run. So yes things run in parallel, but tasks/projects with dependsOn are sorted and paused as long their parents have not finished/been run (and as long as they are in the list of tasks to be run).

Then on project level, it also does the same thing, only it makes sure the task being run for the projects, it sorts the projects in a way that makes dependants run at the end of their parents.

This is useful when, say building apps that don't work when their libs are not build before them. So these apps will have to wait for the libs to finish building first.

Describe the solution you'd like

tasks:
  # Command name [required]
  simple-1:
    cmd: |
      echo "hello world"
    desc: simple command 1

  # Short-form for a command
  simple-2: echo "hello world"
    dependsOn: simple-1

  # Short-form for a command
  simple-3: echo "hello world"

When this is run in parallel, it doesn't matter which task starts first, simple-2 will have to wait for simple-1 to finish. simple 1/3 wait for nobody and will be run in parallel.

projects:
  api:
    path: applications/backend/good-api
    dependsOn: plugger

  app:
    path: applications/frontend/good-app
    dependsOn: plugger

  plugger:
    path: plugins/plugin-that

  plog:
    path: plugins/plugin-2

Same goes for the projects. a mani run build -a will build these in order without messing it up; plog & plugger will run parallel, but api and app will wait for plugger to finish before they run in parallel.

Additional context

To get around the current limitation I have to remember that I have to run these tasks on these projects before i do on these projects. When I write tasks for this, the whole configuration becomes complex as I have to disable parallel and configure and order them in the config. Instead of just telling the program that this project depends on this project, so however order you run them, as long as they are in the same list of projects to be run, always run dependents at the end and wait for their parents to finish running.

Failure on Mac M1 ARM

Unfortunately I get a panic like this:

| Cloningfatal error: concurrent map writes

goroutine 86 [running]:
runtime.throw(0x1043f78e4, 0x15)
	/opt/hostedtoolcache/go/1.16.10/x64/src/runtime/panic.go:1117 +0x54 fp=0x140002b3d40 sp=0x140002b3d10 pc=0x104239734
runtime.mapassign_faststr(0x10447d160, 0x140000b2000, 0x140000146d8, 0x18, 0x0)
	/opt/hostedtoolcache/go/1.16.10/x64/src/runtime/map_faststr.go:211 +0x3c0 fp=0x140002b3db0 sp=0x140002b3d40 pc=0x104219c70
github.com/alajmo/mani/core/dao.CloneRepo(0x1400001a060, 0x21, 0x140000146d8, 0x18, 0x140001c6800, 0x38, 0x0, 0x0, 0x14000198940, 0x40, ...)
	/home/runner/work/mani/mani/core/dao/project.go:194 +0x4b0 fp=0x140002b3f20 sp=0x140002b3db0 pc=0x1043d9fd0
runtime.goexit()
	/opt/hostedtoolcache/go/1.16.10/x64/src/runtime/asm_arm64.s:1130 +0x4 fp=0x140002b3f20 sp=0x140002b3f20 pc=0x10426bd14
created by github.com/alajmo/mani/core/dao.Config.CloneRepos
	/home/runner/work/mani/mani/core/dao/project.go:111 +0x808

goroutine 1 [semacquire]:
sync.runtime_Semacquire(0x1400008e258)
	/opt/hostedtoolcache/go/1.16.10/x64/src/runtime/sema.go:56 +0x38
sync.(*WaitGroup).Wait(0x1400008e250)
	/opt/hostedtoolcache/go/1.16.10/x64/src/sync/waitgroup.go:130 +0x74
github.com/alajmo/mani/core/dao.Config.CloneRepos(0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x140001c3590, 0x1, 0x1, 0x140001da000, ...)
	/home/runner/work/mani/mani/core/dao/project.go:122 +0x190
github.com/alajmo/mani/core/dao.Config.SyncProjects(0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x140001c3590, 0x1, 0x1, 0x140001da000, ...)
	/home/runner/work/mani/mani/core/dao/config.go:566 +0x214
github.com/alajmo/mani/cmd.runSync(0x1046194a0, 0x1)
	/home/runner/work/mani/mani/cmd/sync.go:36 +0xdc

while running mani sync on a Mac M1 ARM based machine

Installed via brew.

Additional context
Mani version:

$ mani version
Version:    0.10.0
Commit:     af8f8a0e98f0a3eed64ed616357a482dd6eb7fd2
Date:       2021-11-10T10:12:45Z

$ file /opt/homebrew/bin/mani 
/opt/homebrew/bin/mani: Mach-O 64-bit executable arm64

If you need more details please ping me... I appreciate to. help...

Open project in same window

It would be nice to be able to define that when opening projects from the Project Manager, that the project will open in the current window. Now it opens a new window for each project.

Thanks!

nvm: command not found

• I have the latest version of mani
• I have searched through the existing issues

Info

• OS

  • Linux
  • Mac OS X
  • Windows
  • other

• Shell

  • Bash
  • Zsh
  • Fish
  • Powershell
  • other

• Version: 0.22.0

Problem / Steps to reproduce

nvm is already installed on my computer. but when I run mani -p projectName "nvm -v"
I get this error:

projectName| sh:nvm:command not found
projectName | exit status 127

Mani sync all o specific branches

Hi guys! I'm using Mani a lot and I think it's a good tool!

I noticed that there is no possibility to sync all my repositories and also checkout the files of specific branches during the sync (like for example the dev and test branch that I have in all the projects).

Sometime the dev is calling develop, so the command don't need to fail if the branch is not existing, but raise an alert.

Would be good to have the possibility to list all the branches and launch the checkout in parallel of every combination.

There is another way to do it using the run command for example?

Thank you!

Currently the first `mani sync` fails partially - next execution works

I have a mani.yml file which contain a number of repositories (113) which can be cloned without entering credentials. The problem happens if I simply run mani sync.. which is shown like this:

$ mani sync 
✓ archetype
✕ its

✓ maven
✓ dist-tool
✕ doxia

✓ sitetools
✕ converter

✓ linkcheck
✓ enforcer
✕ indexer

✕ env

✓ lib
✓ jxr
✕ maven-site

✓ classworlds
✕ archiver

✓ cli
✕ compiler

✓ digest
✕ i18n

✓ interactivity
✓ interpolation
✓ io
✓ languages
✓ resources
✓ velocity
✓ modello
✓ plexus-components
✕ plexus-containers

✓ plexus-pom
✕ utils

✕ plugin-testing

✓ plugin-tools
✓ maven-ear-plugin
✓ maven-acr-plugin
✕ maven-ant-plugin

✓ maven-antrun-plugin
✕ maven-assembly-plugin

✕ maven-changelog-plugin

✕ maven-changes-plugin

✕ maven-checkstyle-plugin

✓ maven-clean-plugin
✓ maven-compiler-plugin
✕ maven-dependency-plugin

✓ maven-deploy-plugin
✓ maven-doap-plugin
✓ maven-docck-plugin
✓ maven-ejb-plugin
✕ maven-gpg-plugin

✓ maven-help-plugin
✕ maven-install-plugin

✕ maven-invoker-plugin

✓ maven-jar-plugin
✓ maven-jarsigner-plugin
✓ maven-javadoc-plugin
✓ maven-jdeprscan-plugin
✓ maven-jdeps-plugin
✓ maven-jlink-plugin
✕ maven-jmod-plugin

✓ maven-linkcheck-plugin
✓ maven-patch-plugin
✓ maven-pdf-plugin
✕ maven-pmd-plugin

✕ maven-project-info-reports-plugin

✓ maven-rar-plugin
✓ maven-remote-resources-plugin
✕ maven-repository-plugin

✓ maven-resources-plugin
✕ maven-scm-publish-plugin

✓ maven-scripting-plugin
✓ maven-shade-plugin
✓ maven-site-plugin
✕ maven-source-plugin

✕ maven-stage-plugin

✕ maven-toolchains-plugin

✕ maven-verifier-plugin

✓ maven-war-plugin
✕ apache

✓ maven
✕ release

✓ ant-tasks
✕ resolver

✕ scm

✕ archiver

✕ artifact-resolver

✕ artifact-transfer

✓ common-artifact-filters
✕ dependency-analyzer

✓ dependency-tree
✓ downloader
✓ file-management
✕ filtering

✕ invoker

✓ jarsigner
✓ mapping
✕ osgi

✓ project-utils
✓ reporting-api
✓ reporting-exec
✓ reporting-impl
✓ runtime
✓ script-interpreter
✕ shared-incremental

✕ shared-io

✕ shared-jar

✕ shared-resources

✕ shared-utils

✕ verifier

✕ default

✕ fluido

✕ studies

✕ surefire

✓ wagon

Failed to clone all projects

I rerun mani sync

$ mani sync 
✓ archetype
✓ its
✓ maven
✓ dist-tool
✓ doxia
✓ sitetools
✓ converter
✓ linkcheck
✓ enforcer
✓ indexer
✓ env
✓ lib
✓ jxr
✓ maven-site
✓ classworlds
✓ archiver
✓ cli
✓ compiler
✓ digest
✓ i18n
✓ interactivity
✓ interpolation
✓ io
✓ languages
✓ resources
✓ velocity
✓ modello
✓ plexus-components
✓ plexus-containers
✓ plexus-pom
✓ utils
✓ plugin-testing
✓ plugin-tools
✓ maven-ear-plugin
✓ maven-acr-plugin
✓ maven-ant-plugin
✓ maven-antrun-plugin
✓ maven-assembly-plugin
✓ maven-changelog-plugin
✓ maven-changes-plugin
✓ maven-checkstyle-plugin
✓ maven-clean-plugin
✓ maven-compiler-plugin
✓ maven-dependency-plugin
✓ maven-deploy-plugin
✓ maven-doap-plugin
✓ maven-docck-plugin
✓ maven-ejb-plugin
✓ maven-gpg-plugin
✓ maven-help-plugin
✓ maven-install-plugin
✓ maven-invoker-plugin
✓ maven-jar-plugin
✓ maven-jarsigner-plugin
✓ maven-javadoc-plugin
✓ maven-jdeprscan-plugin
✓ maven-jdeps-plugin
✓ maven-jlink-plugin
✓ maven-jmod-plugin
✓ maven-linkcheck-plugin
✓ maven-patch-plugin
✓ maven-pdf-plugin
✓ maven-pmd-plugin
✓ maven-project-info-reports-plugin
✓ maven-rar-plugin
✓ maven-remote-resources-plugin
✓ maven-repository-plugin
✓ maven-resources-plugin
✓ maven-scm-publish-plugin
✓ maven-scripting-plugin
✓ maven-shade-plugin
✓ maven-site-plugin
✓ maven-source-plugin
✓ maven-stage-plugin
✓ maven-toolchains-plugin
✓ maven-verifier-plugin
✓ maven-war-plugin
✓ apache
✓ maven
✓ release
✓ ant-tasks
✓ resolver
✓ scm
✓ archiver
✓ artifact-resolver
✓ artifact-transfer
✓ common-artifact-filters
✓ dependency-analyzer
✓ dependency-tree
✓ downloader
✓ file-management
✓ filtering
✓ invoker
✓ jarsigner
✓ mapping
✓ osgi
✓ project-utils
✓ reporting-api
✓ reporting-exec
✓ reporting-impl
✓ runtime
✓ script-interpreter
✓ shared-incremental
✓ shared-io
✓ shared-jar
✓ shared-resources
✓ shared-utils
✓ verifier
✓ default
✓ fluido
✓ studies
✓ surefire
✓ wagon

All projects synced

The second call produces a correct result.

Also it works without any issue if I use mani sync --parallel=false which indicates there is some kind of issue related to the parallel execution.

What I have also observed is that only 2 cores seemed to be used instead of the available ones (this is less important)..

If you need more information please ping me

Option to disable "Running" output

Is your feature request related to a problem? Please describe

Currently writing mani output to file will include the "Running" progress status

Describe the solution you'd like

Add a flag to silent the output (-s, --silent) which skips extra progress report.

Additional context

Provide way to add/delete/clear tags

Is your feature request related to a problem? Please describe

I use mani to manage a lot of repositories. Since I also frequently change my working/ active repositories, I would like to simply define "active" tagged projects where I can execute tasks faster (mani run --tags active ...). I want to prevent to execute some long running tasks on not needed projects.

Describe the solution you'd like

I would like to have extended the CLI which supports CRUD methods for tags (similar to kubectl, kubectl get/create/delete deplyoments )

• mani add tag <tag> --project - add tag to project in mani.yaml. --project is optional and could also be retrieved using current dir (compare with project dir)
• mani remove tag <tag> --project - remove tag of project in mani.yaml. --project is optional and could also be retrieved using current dir (compare with project dir)
• mani clear tag <tag> remove tag of all projects

Additional context

• That the YAML parser removes the comments (addressed in #43) is not important for my use case. A setting allowAutomaticOverride: true could be added to the mani.yaml. If this setting is not present, the tag is not added and a warning message is displayed with a hint for this setting. If it is true, override of mani.yaml is accepted.
• The feature can also be implemented without mani change. Necessary helper methods can be implemented easily. But I would find a support in the context of mani handy, but time consuming to implement.

Off Topic

I was looking for a tool to easily manage my repos, but everyone was forcing me in a direction I didn`t want. mani is very flexible and a great timesaver. Therefore a big thank you.

Add a command to register repos

Currently, mani works with a YAML file, creating which can be a chore if you have a bunch of repositories in a folder.

It would be great if mani had a command like register which would add the section for that repo to the YAML.

So someone could do mani register * and all the folders that are git repos would be added to the YAML.

Mani env fails on Windows when specifying bash shell if WSL is installed

• [x ] I have the latest version of mani
• [ x] I have searched through the existing issues

Info

• OS

  • Linux
  • Mac OS X
  • [ x] Windows
  • other

• Shell

  • [ x] Bash
  • Zsh
  • Fish
  • Powershell
  • other

Problem / Steps to reproduce

Using shell: bash on windows causes Windows to search for bash.exe. If WSL is installed, C:\Windows\System32\bash.exe supersedes any other bash in PATH, such as, say, cmder's bash.

WSL bash does not inherit environment variables from the calling process as it is invoking an entirely different operating system, where as cmder bash does.

It is possible to specify the full path to bash.exe but then the shell: command becomes nonportable.

Example assumes shell path for both is valid.

projects:
  gitignore:
    url: [email protected]:github/gitignore.git
    env:
      testenv: success
targets:
  default:
    all: true
tasks:
  example:
    cmd: echo got $testenv

# uncomment one or the other 
#shell: C:\cmder\vendor\git-for-windows\bin\bash.exe
shell: c:\windows\system32\bash.exe

mani sync
mani run example

Allow hiding empty columns

Is your feature request related to a problem? Please describe

Currently there is no option for hide empty columns in table format.

Describe the solution you'd like

Config to hide empty columns in table format

Additional context

v0.20 mani sync bug

I just installed the latest version of mani on arch, and I want to report a new bug I noticed.

I think the bug is related to the fact that I store my mani.yaml file within a mani repo. See #27.

For example, my mani.yaml contains:

  spotidry:
    path: ~/Documents/GitRepos/OpenSource/spotidry
    url: https://github.com/mikeboiko/spotidry

When I run mani -c ~/Documents/GitRepos/Linux/config/mani.yaml sync, my repo ends up in ~/Documents/GitRepos/Linux/config/spotidry

Allow inclusion of root dir

Is your feature request related to a problem? Please describe

I have a nodejs monorepo in the root and it generates node_modules dir on yarn install. So I have created a task that cleans these kind of dirs. The script simply does rm -rfv node_modules but I'd like to also include the root dir and remove that said node_modules dir.

Describe the solution you'd like

Allow a built-in tag and target 'root' to include the root dir as well in any operations.

Additional context

I thought that the targets cwd: true option or -k makes Mani include the root dir wherein the command is ran, but it doesn't do anything.

Define how many parallel processes gets used

Is your feature request related to a problem? Please describe

Setting ControlMaster throws an error when mani creates to many processes:

mux_client_request_session: session request failed: Session open refused by peer
ControlSocket /tmp/git@<url>:22 already exists, disabling multiplexing

Being able to limit somehow would be nice.

Describe the solution you'd like

Add the possibility to set how many parallel processes created when invoking --parallel.

Additional context

mani cd (a way to change to a project's directory)

Is your feature request related to a problem? Please describe

Ok so I wish there was a way of quickly moving between directories, so that I can do what I want from there without invoking Mani. One of the reasons is shorter commands and the other is the way the output is displayed. Sometimes the output is just modified such that it doesn't make it as legible as it normally is with the original command that's being run.

Describe the solution you'd like

The solution is very simple, a way to change the current directory to the filter that is resolved by either tags, project or path eg:

given that we have the following projects configured:

projects:
  root:
    path: ./
    tags: [root]

  api:
    path: applications/backend/good-api

  plugger:
    path: plugins/plugin-that-we-want
    tags: [lib]

  plog:
    path: plugins/plugin-that-we-want
    tags: [lib]

mani cd -p=api changes to ./applications/backend/good-api/

and

mani cd -p=plugger changes to ./plugins/plugin-that-we-want/

As mentioned, this works with all the filters that mani provides. In the case where there is more than 1 directory that result from the query (eg: -t=lib), then it switches to the first hit.

mani cd just changes to the root directory

Additional context

I tried creating tasks that do this, but it seems like Mani changes the directory back to whatever current directory it was in when it was run.

connected-light theme for table

Is your feature request related to a problem? Please describe

Add connected-light theme for table output. Currently this theme is only available for tree output.

Describe the solution you'd like

~ mani.yaml ~
themes.default.table.style: connected-light

Additional context

mani sync does nothing

I created a simplified mani.yaml file for this example:

projects:
  Vim:
    path: ~/Documents/GitRepos/Vim
    url: https://bitbucket.org/mikeboiko/Vim
    # clone: git clone https://bitbucket.org/mikeboiko/MainSynchredible

  AccuTuneDocs:
    path: ~/Documents/GitRepos/AccuTune/Docs
    url: https://github.com/mikeboiko/AccuTuneDocs
    # clone: git clone https://github.com/mikeboiko/AccuTuneDocs

When I run mani -c ~/Documents/GitRepos/Linux/config/mani.yaml sync, I get no stdout or stderr output.

My git is configured with credential helpers for GitHub and BitBucket, so I don't need to be prompted for credentials.

I should also point out that I'm keeping my mani.yaml file inside one of my repos, and not inside the root folder of all the repos. Not sure if this could be causing an issue somehow.

I tried uncommenting the clone lines in each project, but there was still no output and no actions performed.

Unable to access env variables when running on Windows

• I have the latest version of mani
• I have searched through the existing issues

Info

• OS

  • Linux
  • Mac OS X
  • Windows
  • other

• Shell

  • Bash
  • Zsh
  • Fish
  • Powershell
  • other

• Version: 0.21.0

Problem / Steps to reproduce

I am unable to access the environment variables defined at either the project or task level when running on Windows 10

projects:
  Repo-Manager:
    path: .

  Server:
    url: <Git URL>
    desc: The Server
    env:
      branch: test
    tags: [server]
   
tasks:
  test:
    desc: simple test task
    target:
      tags: [server]
    cmd:  echo $branch
  testInlineEnv:
    desc: simple test task
    env:
      branch: test
    target:
      tags: [server]
    cmd:  echo $branch

mani run test
mani run testInlineEnv

init with multiple repos with the same name

If there are multiple repos with the same name within different subdirectories, mani init creates an invalid mani.yaml file where keys appear multiple times within the projects object.

A quick solution would be to prepend part of the path to distinguish them in case of repetitions.

Relative paths and imported configurations

This is not a bug report but just a request for the confirmation of the behaviour of mani w.r.t. the relative paths of imported configuration files. The documentation says that relative project paths are resolved w.r.t. to the config file; but in the case that projects are defined in an included configuration file, it's not clear whether they are resolved w.r.t. the path of the included or the including (root) configuration file. Apparently, mani takes the former approach (i.e., path of the included file, see below). I think that it's fine (actually rather useful), but I'd like to ask whether this is the intended behaviour and we can count on that also for future releases. I think that it should be mentioned in the documentation to avoid ambiguities.

The example below demonstrates the behaviour:

Directory structure

❯ tree
.
├── projects
│   ├── mani_projects.yaml
│   ├── project1
│   └── project2
└── tools
    └── mani.yaml

Configuration files

# projects/mani_projects.yaml
projects:
  project1: {}
  project2: {}

# tools/mani.yaml
import:
  - ../projects/mani_projects.yaml

env:
  MANI_WD: $(pwd)

projects:
  root:
    path: .

tasks:
  pwd: |
    target=$(pwd)
    common_part=${MANI_WD}
    back=
    while [ "${target#$common_part}" = "${target}" ]; do
      common_part=$(dirname $common_part)
      back="../${back}"
    done
    echo "project directory: ./${back}${target#$common_part/}"

Showing the directories of the projects

❯ mani -c tools/mani.yaml run pwd -a

TASK [pwd] *********************************************************************************************************

root | project directory: ./tools

TASK [pwd] *********************************************************************************************************

project1 | project directory: ./projects/project1

TASK [pwd] *********************************************************************************************************

project2 | project directory: ./projects/project2

How do I choose which branch I want to pull？

I want to pull different branches for different projects, but even if I change the env value in the mani.yaml file, it still pulls the master or main branch by default when I do a mani sync.

projects:
  example:
    path: .

  pinto:
    path: frontend/pinto
    url: https://github.com/alajmo/pinto
    tags: [frontend]
    env:
      branch: feat/switch-ui

  dashgrid:
    path: frontend/dashgrid/../dashgrid
    url: https://github.com/alajmo/dashgrid
    tags: [frontend, misc]

  template-generator:
    url: https://github.com/alajmo/template-generator
    tags: [cli]
    env:
      branch: feat-replace

For pinto and template-generator, both projects still pull the main and master branches.

Option to define parameters in projects

Is your feature request related to a problem? Please describe.
I have a mani.yaml with a larger number of repos..as intended. Given a simple brief example:

projects:
    p1:
      path: x
      url: https://.../repos/x.git
    p2:
      path: y
      url: https://.../repos/y.git
tasks:
  upd:
    desc: Update all given projects.
    output: text
    commands:
      - name: switch to master
        cmd: git switch master
      - name: pull update
        cmd: git pull --all -p

So in general the usage is fine but I have one issue. I have a lot of git repos (200+) but not all using the same naming for the default branch. Some use main some use master and others use dev... so the definition of a task like the above is
not usable for all cases.

Describe the solution you'd like
It would be great having a way to define a kind of a parameter for the task something like (just an idea):

projects:
    p1:
      path: x
      url: https://.../repos/x.git
      parameters:
        - branch: main
    p2:
      path: y
      url: https://.../repos/y.git
      parameters:
        - branch: master
tasks:
  upd:
    desc: Update all given projects.
    output: text
    commands:
      - name: switch to ${branch}
        cmd: git switch ${branch}
      - name: pull update
        cmd: git pull --all -p

Maybe there should be used a different syntax than using ${..} to separate them from the environment variables given for all tasks via env:.....

task alias

Is your feature request related to a problem? Please describe

It'd be useful to have an alias for a task. Such will make it easier to work in a large team and reduce mental migration from tools used in different platforms and environments.

Eg: Windows cmd: dir, but in unix it's ls

In addition this will also provide a way to invoke the same task in many different ways, avoiding the same mental clash.

Describe the solution you'd like

  build:clean:
    aliases: ['build+clean', 'build-clean', 'clean-build'],
    # next is meant for single aliases
    alias: build+clean
    desc: clean & build artifacts, which may produce dirs ("dist", "build", ".cache")
    spec: default
    commands:
      - task: rm:build
      - task: build

Additional context

List of tasks would also show these aliases.

documentation links are resulting in 404

documentation links in the readme are resulting in a 404 becoz there is a double docs/docs in the links.

https://github.com/alajmo/mani/blob/main/docs/docs/commands.md

Error message for invalid yaml with mani edit command

Hello,

Is your feature request related to a problem? Please describe.
When the mani.yaml is invalid, there is a yaml: unmarshal errors error, the behavior is normal.
But when you do mani edit it also print this error and prevents the file from being opened. So the only way to fix the error in the yaml file is to open the file with an editor.

Describe the solution you'd like
To always be able to open the mani.yaml file, would it be possible to remove the yaml validity check for the command mani edit ?

Additional context
N/A

Thanks in advance for your help