Closed derberg closed 7 months ago
Great summary of the options.
Creating the action directly in the CLI repo does sound the best, as long as the action does not get lost in all the other CLI documentation. Google searching made it easy to find this repo. Hopefully that would still work if you migrated it.
This issue has been automatically marked as stale because it has not had recent activity :sleeping:
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 :heart:
still needed
This issue has been automatically marked as stale because it has not had recent activity :sleeping:
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 :heart:
Let's do it in 2 steps:
current scope:
Generator for AsyncAPI documents
to Generator, validator, converter and others - all in one for your AsyncAPI docs
github-action-for-generator
to github-action-for-asyncapi-cli
template
or othersHey @derberg, can I work on this?
I want to work on this issue.
@derberg I would like to work on this one as I have experience of working with GH so I think I will be able to resolve this one
Bounty Issue's End Of Life (EOL): 2024-02-29 23:59:59 UTC-12:00
Hi I would love to work on this! I've had worked with gh actions in the past extensively :)
In this issue I'll go with @Shurtu-gal that already contributed in AsyncAPI organization a number of GitHub-actions related improvements. Ashish also know AsyncaPI CLI already very well and this GH Action work involves it big time.
This is an advanced issue and I prefer to select someone who has initial knowledge and understanding of our complex setup.
Complexity Level | Assignment date (by GitHub) | Start date (by BP rules) | End date (by BP rules) | Draft PR submission | Final PR submission | Final PR merge |
---|---|---|---|---|---|---|
Advanced | 2023-11-13 | 2023-11-20 | 2024-01-12 | 2023-12-08 | 2023-12-29 | 2024-01-12 |
we still need a lot of custom action parameters, like
template
or others.
@derberg as we would be exposing the cli interface directly, should I take parameters as a json and pass them unto cli in docker or something else. As the CLI has various topics and subtopics inside of it further down.
OR are we only looking for specific functions for now?
Due to unpredicted circumstances that could not be foreseen and are beyond the control of the AsyncAPI Maintainer (@derberg), the Bounty Issue's Timeline is frozen for an indefinite amount of time.
AsyncAPI Maintainer (@derberg) had regained a confident online presence in Slack, so the Bounty Issue's Timeline is extended by four weeks.
Complexity Level | Assignment date (by GitHub) | Start date (by BP rules) | End date (by BP rules) | Draft PR submission | Final PR submission | Final PR merge |
---|---|---|---|---|---|---|
Advanced | 2023-11-13 | 2023-11-20 | 2024-02-09 | 2024-01-05 | 2024-01-26 | 2024-02-09 |
@asyncapi/bounty_team
AsyncAPI Maintainer (@derberg) was absent online in Slack for one period of three working days in a row, so all target dates of the Bounty Issue's Timeline are extended by two calendar weeks.
Complexity Level | Assignment date (by GitHub) | Start date (by BP rules) | End date (by BP rules) | Draft PR submission | Final PR submission | Final PR merge |
---|---|---|---|---|---|---|
Advanced | 2023-11-13 | 2023-11-20 | 2024-02-23 | 2024-01-19 | 2024-02-09 | 2024-02-23 |
@aeworxet bounty completed like a pro ๐ช๐ผ you can go ahead and instruct @Shurtu-gal how to get the payment
Please go to the AsyncAPI's OpenCollective page and submit an invoice for USD 400.00
with the subject Bounty github-action-for-generator#281
, tag bounty
.
When I worked on this action some time ago, my main motivation was:
Now times are different ๐
I think it would be better:
Generator for AsyncAPI documents
toGenerator, validator, converter and others - all in one for your AsyncAPI docs
github-action-for-generator
togithub-action-for-asyncapi-cli
Or: Or we just archive this repo and create action directly in AsyncAPI CLI - example how a friend does it (CLI and GH action for it in one repo) https://github.com/mszostok/codeowners-validator. I think it makes sense, especially that in ourcase GH Action would anyway always reflect the CLI version. Current action we would just archive, set as deprecated and link to the new one.
Thoughts?