Make contexts shareable about cli HOT 37 CLOSED

Working closely with @derberg to ensure the development is going in right direction.
Thought last week I'm ready for a draft PR but no.

from cli.

Bounty Program Timeline

(target dates are updated by the duration of absence of the person in charge from AsyncAPI side in the amount of two weeks + one week)

from cli.

I like this idea a lot!

from cli.

would like to start by talking about the data structure for context. All context is doing right now is storing file paths that supposedly point to a spec path. Storing it in a key-value pair. So context in general looks something like this.

interface Context {
  current?: string,
  store: {
    [name: string]: string
  }
}

ContextService is loading this data and providing functions to read and manipulate this. Now the problem is there is a case that the global .asyncapi might be missing. For this case, the loader is throwing a ContextFileNotFoundError which serves the purpose, but this means we have to check for this error every time we are using this. This is making the code messy, I would like to give some examples -

While autoloading the spec file, there was a case where when there was no global .asyncapi file it was unable to autodetect spec files in the working directory as it was throwing the ContextFileNotFoundError. Had to work around like this.

Was playing around with the idea that we don't throw an error rather return an object with undefined context.

import * as fs from 'fs';
import * as path from 'path';


const SPEC_FILE_PATH = path.resolve(__dirname, 'asyncapi');

interface Context {
  current?: string,
  store: {
    [name: string]: string
  }
}

const saveContext = (ctx: Context) => {
  fs.writeFileSync(SPEC_FILE_PATH, JSON.stringify(ctx), {encoding: 'utf-8'});
}

class ContextService{
  constructor(private _context:Context | undefined){
    
  }

  current(){
    return this._context?.current;
  }

  context(contextName?:string){
    if(!contextName) return this._context;
    return this._context?.store[contextName];
  }

  isContext(){
    return typeof this._context !== 'undefined'
  }

  addContext(name: string, specPath: string){
    if(this._context) {
      this._context.store[name] = specPath;
      saveContext(this._context)
    }
    return true
  }

  static load(){
    try{
      const ctx = fs.readFileSync(SPEC_FILE_PATH, 'utf-8');
      return new ContextService(JSON.parse(ctx) as Context);
    }catch(e) {
      return new ContextService(undefined);
    }
  }
}

const ctxService = ContextService.load();
console.log(ctxService.isContext());
console.log(ctxService.addContext('test', 'url/to/specFile'))

from cli.

Yeah, I don't think it should throw an error as it's optional to have .asyncapi files. Much better to return undefined IMHO.

from cli.

This issue has been automatically marked as stale because it has not had recent activity 😴

It will be closed in 120 days if no further activity occurs. To unstale this issue, add a comment with a detailed explanation.

There can be many reasons why some specific issue has no activity. The most probable cause is lack of time, not lack of interest. AsyncAPI Initiative is a Linux Foundation project not owned by a single for-profit company. It is a community-driven initiative ruled under open governance model.

Let us figure out together how to push this issue forward. Connect with us through one of many communication channels we established here.

Thank you for your patience ❤️

from cli.

Removing stale label as we still plan to implement this. If someone is up for this, it's a good one!

from cli.

This issue has been automatically marked as stale because it has not had recent activity 😴

It will be closed in 120 days if no further activity occurs. To unstale this issue, add a comment with a detailed explanation.

There can be many reasons why some specific issue has no activity. The most probable cause is lack of time, not lack of interest. AsyncAPI Initiative is a Linux Foundation project not owned by a single for-profit company. It is a community-driven initiative ruled under open governance model.

Let us figure out together how to push this issue forward. Connect with us through one of many communication channels we established here.

Thank you for your patience ❤️

from cli.

This issue has been automatically marked as stale because it has not had recent activity 😴

It will be closed in 120 days if no further activity occurs. To unstale this issue, add a comment with a detailed explanation.

There can be many reasons why some specific issue has no activity. The most probable cause is lack of time, not lack of interest. AsyncAPI Initiative is a Linux Foundation project not owned by a single for-profit company. It is a community-driven initiative ruled under open governance model.

Let us figure out together how to push this issue forward. Connect with us through one of many communication channels we established here.

Thank you for your patience ❤️

from cli.

Dear bot, keep this issue open. Thanks!

from cli.

This issue has been automatically marked as stale because it has not had recent activity 😴

It will be closed in 120 days if no further activity occurs. To unstale this issue, add a comment with a detailed explanation.

There can be many reasons why some specific issue has no activity. The most probable cause is lack of time, not lack of interest. AsyncAPI Initiative is a Linux Foundation project not owned by a single for-profit company. It is a community-driven initiative ruled under open governance model.

Let us figure out together how to push this issue forward. Connect with us through one of many communication channels we established here.

Thank you for your patience ❤️

from cli.

Still relevant.

from cli.

The scope here is to:

• make CLI read context configuration from CWD
• make current context home directory storage a fallback to new CWD based
• prepare code for an option to long-term have a flag in every command to specify a custom location of the context. So instead of home or CWD, someone can specify custom file system location of context config. Do not implement, outcome should be a proper amount of good-first-issues that enable further implementation

from cli.

This issue is part of the AsyncAPI Bounty Program, interested contributors need to follow the guidelines below to ensure fairness and timely completion of assigned tasks:

Task Assignment

The assignment of tasks will be prioritized in the following order:

• AsyncAPI maintainers (from any repository)
• Regular contributors (individuals who have merged three or more pull requests)
• Other (if an individual doesn't fall under the above, the maintainer can determine the criteria i.e regular volunteers, etc)

We encouraged everyone to apply as long as the task is for you (falls under your skill set). We will not be using the first comment - get assigned method for assignments. Instead, we will provide 3 days to consider all individuals interested before assigning any bounty task.

Deadline

To maintain accountability and ensure the timely completion of the deadline for this task will be 6 - 8 weeks from the date of assignment. If a contributor requires an extension on their task, it should be communicated and approved by the maintainer.

Issue Tracking and Updates

Contributors must provide weekly updates on the task they are working on to help maintainers stay informed of progress. If a contributor fails to provide an update, they will be reminded via a ping. If a contributor fails to provide an update after three pings over three weeks, we will assume they have silently dropped the issue, and it will be reassigned to someone else.

Issue Drop-outs

Any contributor who drops an assigned issue will be penalized and will not be eligible to participate in the bounty program for 6 months. We understand that unforeseen circumstances can arise, and dropping an assigned issue may be unavoidable in some cases. However, we believe that enforcing this penalty is necessary to ensure the effectiveness of the bounty program, respect maintainer time, and honor the efforts of other contributors who could have solved the issue but were unable to do so due to the drop-out.

We encourage all contributors to follow these guidelines to ensure a fair and timely completion of tasks assigned through our bounty program.

from cli.

more context for the issue:

for now context are a “global” thing, like bash profile or git config -> os.homedir()

the idea is that this approach should not be default, but a fallback

by default, CLI should search for .asyncapi (probably we should rename to .asyncapi_cli 🤔 ) in the CWD and then cascading search for it up to the root of the repository - then if not found, look for the global one

so for example you have context file only for given repository, keep it in git with rest of the code, or have few context files in one repo in case you have mono repo

from cli.

I would like to work on this issue.

from cli.

@aeworxet perfect, please go ahead and ask questions whenever help is needed.

from cli.

Some questions.

1

What should happen in this situation?

/home/userhomedir/web_development/personal/foss/asyncapi/cli/fork/src/models/.asyncapi
/home/userhomedir/web_development/personal/foss/asyncapi/cli/fork/src/.asyncapi
/home/userhomedir/web_development/personal/foss/asyncapi/cli/fork/.asyncapi
/home/userhomedir/.asyncapi

Should the search stop on first found .asyncapi file?

2

Is there a real .asyncapi file with real data so I could test not only its existence or whether it can be simply read, but whether it can be IMPORTED and whether it satisfies all requirements of interface IContextFile {}?

from cli.

from cli.

1

if you run asyncapi in /home/userhomedir/web_development/personal/foss/asyncapi/cli/fork/src/models it should pick /home/userhomedir/web_development/personal/foss/asyncapi/cli/fork/src/models/.asyncapi

not sure it answers your question? cwd basically

2

you can create it yourself, just do asyncapi context add for example

and here is an example with complex project structure and multiple documents https://github.com/asyncapi/spec/tree/master/examples/social-media

from cli.

Hey @aeworxet how is it going so far?

from cli.

Bounty Program Timeline

Please note that dates represent deadlines, not specific dates, so if the goal is reached sooner, it's better.

from cli.

Should CLI context file's name be changed from .asyncapi to .asyncapi-cli, by analogy with .asyncapi-tool?

from cli.

no strong opinion from my side, both are ok I think, I do not see scenario where in one repo someone would have .asyncapi-tool and .asyncapi. So .asyncapi is pretty ok I think

from cli.

If there's no strong opinion, I'd rather make it .asyncapi-cli. Just in case there appears a Big Universal AsyncAPI Framework at some moment which will proudly utilize filename .asyncapi.
And while this context functionality is not much in use, because the more users use it, the harder it is to migrate to a new name in case of a need.

from cli.

Big Universal AsyncAPI Framework at some moment which will proudly utilize filename .asyncapi

I like that! 😃

from cli.

PR update postponed until Executive Director returns from vacation.

from cli.

A break for you 😊

from cli.

Executive Director 👀

next time please do not feel blocked by me, there is also @Souvikns that maintains CLI and also the request for shared context came from @fmvilas

but I also understand that you preferred to wait as we discusses some technical details before my holidays.

PR is in Draft mode, so please lemme know if ready for review

from cli.

This was at the same time a Bounty Program usecase. If your vacation would INDEED be a blocking issue, how would the Bounty Program timeline change?
I would propose to increase any stage the issue is at that moment in, by duration of absence of the person in charge from the AsyncAPI side + 1 week, because if such person (Core Developer?) was absent for a month or two (for any reason), the bounty hunter would then have to spend some time getting back to the insides of the issue and nearly unfamiliar at that time his own code.

from cli.

Executive Director

As a giggly alternative I also have Chief Merging Officer.

from cli.

As a giggly alternative I also have Chief Merging Officer.

ok, but only if we write it Chief mErging Officer so I can say I'm a CEO 😆

If your vacation would INDEED be a blocking issue, how would the Bounty Program timeline change?

if I'm a blocker and on holidays or basically maintainer is off and do not respond for some time -> for me it is clear that the time is then like on hold, counter stops

from cli.

It's logical that the time of actual absence is added to the timeline. It is +1 week that needs clarification.

from cli.

sounds good to me, makes sense to add +1. Please add it as feedback comment to the related bounty discussion so we do not forget to address it when we make official bounty program. Let's further discuss there and not in this issue

from cli.

@thulieblack fyi it is taking a bit longer because @aeworxet is adding one more small docs to it and also documentation for the context concept that we did not have initially in the scope

from cli.

@thulieblack last bounty issue completed 🥳

@aeworxet congrats 👏🏼

from cli.

Congratulations @aeworxet 🎉🎉

Please submit an expense via open collective to claim` your bounty

from cli.