Improving Microcks CLI or creating some microcks utility like mksctl

[yada]

[!NOTE] This issue reflects our community's decision to submit projects to the LFX mentorship program. See: https://github.com/orgs/microcks/discussions/1463 Project Idea 1 : Improving Microcks CLI or creating some microcks utility likemksctl

We aim to improve the Microcks CLI by integrating a robust CLI framework like Cobra CLI or by developing a dedicated utility tool. This enhancement will streamline interactions with Microcks, making it easier to install, manage, and extend.

@JulienBreux has started some work on creating a utility tool called mksctl here, so we can take it further.

Key Goals:

• Maintain compatibility with existing test and import commands.
• Enable easy installation via package managers (brew, apt, etc.).
• Provide simple commands (mksctl start, mksctl stop) to manage Microcks instances.
• Expand functionality with new commands (e.g., import from URL, import all files in a directory, create job, list jobs).
• Ensure scalability and community contributions through standard tooling.
• Work has already begun on mksctl, and the initial implementation has been merged into the Microcks CLI 1.x branch.

[Siddhi-agg]

Hi @yada ! I am Siddhi Agrawal, a fellow open-source enthusiast and I am super interested in contributing to this project for this LFX term. I have some experience in CLI tool development by contributing to my ocaml project : ocaml-api-watch through Outreachy. I would love to chat more about the requirements for this project.

Do you have a pretest or any issues for this project that I can solve? Would you want a proposal for selection of LFX mentorship?

[yada]

Hi @Siddhi-agg ,

Thank you for your interest in this project; your help and contribution are greatly appreciated.

Please join as a mentee on the LFX mentorship program; this project is now online. For further details, see my latest comment in this thread: https://github.com/orgs/microcks/discussions/1463#discussioncomment-12067922

The direct link to this project is: https://mentorship.lfx.linuxfoundation.org/project/7ceac2ef-6290-4e2a-87aa-db93d909b27b and click on "Become a Mentee" in the top right corner.

Then, at the beginning of March, we will select mentee(s) and move forward on the project itself with mentors. Thank you Regards, Yacine

[divyansh-prks]

Hi @yada
I am Divyansh , interested in exploring low level stuff (os , computer architecture and design , assembly language ) and i am interested to contribute in this cool project under LFX'25 because it matches my interest . Although i never worked on cli but before directly jumped on to microcks project i have built a small cli tool for checking microcks eligibility . I have applied to Lfx as a mentee .

https://github.com/user-attachments/assets/4afcfdde-c974-46c0-8e66-54dfb52b95a2

I would love to know is there any issue that i can start working on ?

[lbroudoux]

Hey @divyansh-prks, This is a very nice introduction 😉 Please apply as a mentee as @yada explained above. Talk to you soon!

[divyansh-prks]

Thanks! @lbroudoux 😊 btw I have already applied it .

[lbroudoux]

Applications are opened until Feb 18th and the program is actually starting on March 1st. We'll keep you updated!

[hanshal101]

Hey @lbroudoux and @yada , Hanshal here. I am an open-source developer, contributed to various organizations (CNCF too) like BuildSafe, Glasskube, Cyclops, and a couple of Apache's. I have the most experience on CLI. I have extensive experience in Golang and Kubernetes and am currently working at Cloudraft as a DevOps Intern. I'm planning to submit a project proposal for this issue in the LFX Term 1 2025.

Thank you.

[yada]

Hi, all LFX mentorship enthusiasts,

First of all, thanks, as we are glad to see so many mentees request and interest in Microcks 🙌

To reply to "all" recurrent questions we have: No pretests. Selections will be made based on mentees' profiles, motivations and experience. See: https://github.com/cncf/mentoring/blob/main/programs/lfx-mentorship/README.md#mentee-selection-process https://docs.linuxfoundation.org/lfx/mentorship/mentor-guide/mentorship-faqs

Of course, you can always start to join the community and contribute to it (outside of the 7 LFX mentorship projects, as we do not want to bypass the program process and want it to be fair for all). But, yes, starting to contribute is clearly the best way for mentees to check and immerse themself within the community, see what is expected and demonstrate their motivation 😉

Please join us on Discord. We have a dedicated channel for LFX mentorship to centralize messages. See: https://github.com/orgs/microcks/discussions/1463#discussioncomment-12081057

Best regards, Laurent & Yacine (Microcks maintainers)

[lbroudoux]

Following a brainstorming session with @Harsh4902, here's our brain dump and plan for this Epic! 🎉

• Priorities will be refined as we're going forward but we agreed that the first bullet points (1-6) were actually the top priorities
• All the development will happen on the 1.x branch.
• Feel free to review and ask as many questions as you want: directly as comments here or as new discussion on GitHub or Discord for larger topic!

Topics

• [x] New name 😉 => microcks
• [x] Move build to Makefile - #130
• [x] Define testing strategy and implement it on existing commands
  • [ ] Unit tests at the Go level - #132
  • [ ] Integration tests at the Go level (running Microcks with Testcontainers)
  • [ ] Integration tests at the OS level (issuing commands on the CLI binary - Microcks started with a docker run)
• [x] Setup new CI/CD pipeline for building the CLI - #127
  • [x] Adjusting the existing Brew formulae
• [x] Documentation! - #145
  • [x] Initialize README with installation notice, basic commands
  • [x] Complement README or create new markdown files if necessary every time we implement a new feature/command.
• [x] Start / Stop command implementation - #108
  • [x] Design —-driver mechanism
  • [x] Using docker
  • [x] Using podman
• [x] Package for other OS / distros
  • [ ] apt (Linux / Debian likes)
  • [ ] winget (Windows microsoft/winget-cli: WinGet is the Windows Package Manager. This project includes a CLI (Command Line Interface), PowerShell modules, and a COM (Component Object Model) API (Application Programming Interface).)
• [ ] Design questions
  • [x] How to handle complex information for creating or searching commands?
    • [x] As a set of flags —-flag? As JSON as input (validated with Go struct serialization)? As a file?
  • [ ] How to handle output for listing / details commands ?
    • [ ] Only as terminal output? Allow raw formats like JSON or YAML? Like kubectl -o json
• [x] Login / logout command - #154
  • [x] Bypassed if local instance (started with microcks start) is currently running?
  • [x] File for holding current context and account token (with refresh token?)
  • [x] Replace Client credentials (service account)
  • [x] Implement OIDC Browser Authentication flow
  • [x] List / delete authentication context command
  • [x] Associate role with authentication context? => no making sense to me
• [x] Context switching commands - #136
  • [x] Is there a use case for this?
  • [x] Implies storing many context in ~/.microcks or something and allowing to microcks context set <my-context>
• [ ] Import commands
  • [x] import local-file<:primary>,another-local-file<:primary>
    • [ ] Add a --watch option that allows keeping the microcks-cli process running and re-importing stuff on file change only (see https://medium.com/@skdomino/watch-this-file-watching-in-go-5b5a247cf71f for inspiration on how to do this) - #158
  • [x] import-url https://artifact.yaml
    • [ ] Is it possible to add a secret?
  • [x] import-dir ./my-local-resources
  • [ ] import-bundle openid.net:oidc.1.0 --hub https://hub.acme.org with https://hub.microcks.io being the default Hub
  • [ ] import
    • [ ] import url https://artifact.yaml
    • [ ] import dir ./my-local-resources
    • [ ] import bundle openid.net:oidc.1.0 --hub https://hub.acme.org with https://hub.microcks.io being the default Hub
• [ ] Secrets commands
  • [ ] Create Secret: microcks secrets create my-secret --username --password --token ---tokenHeader --caCert
  • [ ] List Secrets: microcks secrets list
• [ ] Service commands
  • [ ] List APIs | Services: microcks services list
  • [ ] Get API | Service: microcks services get 'Pastry API:1.0.0' or microcks services get <id>
• [ ] Import Job commands
  • [ ] Create Import Job: microcks importjobs create https://artifact.yaml <primary> --secret=my-secret

Collaterals

• [ ] Update the GitHub actions
  • [ ] test
  • [ ] import
• [ ] Update the Tekton Tasks
  • [ ] test
  • [ ] import

[lekaf974]

✋ I have recently been introduced to microcks and had been able to use it to mock 2 services (authentication and authorization) to run e2e testing in our CI. This first usage makes me seeing a real potential to your project and I'd like to contribute.

To introduce myself, in my daily life I am a Platform Engineer and have multiple skills (sysadmin, software development, CI/CD, etc.),. After using Open Source Software for decades, I started to contribute regularly to some CNCF projects since ~2 years now and I became a maintainer of https://github.com/meshery/meshery (CNCF Sandbox project) on the CLI based on Cobra Framework.

I'll be happy to help so if you are interested, just let me know.

[Harsh4902]

@lekaf974 Thank you so much for showing interest. We have plenty of things to work on—you can find some tasks above. Let me know which specific task you want to work on, and I'll be happy to share my thoughts 😃.

[lekaf974]

@lekaf974 Thank you so much for showing interest. We have plenty of things to work on—you can find some tasks above. Let me know which specific task you want to work on, and I'll be happy to share my thoughts 😃.

Hi @Harsh4902, I could start with the unit test one for example, it will let me learn the current code base.

[Harsh4902]

@lekaf974 Thank you so much for showing interest. We have plenty of things to work on—you can find some tasks above. Let me know which specific task you want to work on, and I'll be happy to share my thoughts 😃.

Hi @Harsh4902, I could start with the unit test one for example, it will let me learn the current code base.

Yes, sure. Let me know if you need any help 😺

[lekaf974]

✋ I started to experiment the cli 1.x and have some questions that come in my mind. Currently deploying microcks on docker I can access to the UI and import my openapi spec without providing any keycloak credentials but it is required by cli. It looks to me that UX between UI and CLI should be identical, what do you think about it ?

[Harsh4902]

✋ I started to experiment the cli 1.x and have some questions that come in my mind. Currently deploying microcks on docker I can access to the UI and import my openapi spec without providing any keycloak credentials but it is required by cli. It looks to me that UX between UI and CLI should be identical, what do you think about it ?

Currently, for every command, we have to provide values for the flags --microcksURL, --keycloakClientId, and --keycloakClientSecret. We are not currently checking whether Keycloak is enabled in the Microcks instance. It might be helpful to add such checks while creating a Microcks instance using the start command or when adding an instance to the config file. This would allow us to bypass authentication for instances where Keycloak is disabled.

[lekaf974]

@Harsh4902 , still continue to explore a little deeper in the cli and I have some comments regarding current behavior.

1. Having to provide those 3 flags for each commands is not a good UX overall compare to other cli available (eg. kubectl, helm) where those config are managed internally.
2. import-url embedded in import with a dedicated --url flag seems a better UX
3. Seeing place for improvement using Cobra and Viper builtin features
4. I have been able to create a panic with import command providing --microcksURL flags with value http://localhost:8585 instead of http://localhost:8585/api. Think I can create a bug for this. one

[lekaf974]

Reviewing the Topics opened

I have implemented something similar in #score-spec/score-compose#267 recently perhaps could give some ideas

[Harsh4902]

@Harsh4902 , still continue to explore a little deeper in the cli and I have some comments regarding current behavior.

1. Having to provide those 3 flags for each commands is not a good UX overall compare to other cli available (eg. kubectl, helm) where those config are managed internally.
2. import-url embedded in import with a dedicated --url flag seems a better UX
3. Seeing place for improvement using Cobra and Viper builtin features
4. I have been able to create a panic with import command providing --microcksURL flags with value http://localhost:8585 instead of http://localhost:8585/api. Think I can create a bug for this. one

1. with the implementation of login those 3 flags will be removed.
2. we have a plan for sub commands like url and dir under the import command so that it will improve UX.
3. Please suggest any changes. We will definitely work on it.
4. Yes, you can create bug, but localhost:8585/api is the base URL for any further endpoints. If you don't provide /api client will not be able connect.

[Harsh4902]

Reviewing the Topics opened

I have implemented something similar in #score-spec/score-compose#267 recently perhaps could give some ideas

We still have to think about it. We are not yet sure that which resource we are going to print. Also, not sure if there is any requirement for this or not. We have to think about the use cases.

[Caesarsage]

hello @Harsh4902, I would love to join you in contributing to this. I can start off with the importDir

[lbroudoux]

Closing this one as everything is mostly done. Switching to regular issue tracking.