Create GitHub Action that will handle automated bump of internal AsyncAPI dependencies about .github HOT 15 CLOSED

@fmvilas @magicmatatjahu @jonaslagoni
My work is done here. My assumption is that in all new repos, or projects that are still on initial PR, the person responsible for the topic will add this new workflow like all others.

I also updated instruction here #17

Is there anything missing?

from .github.

@jonaslagoni there is no difference between minor, major, patch. It doesn't matter what package version is released, it matters how it is used by the dependency, is it prod dependency or dev dependency. And you can decide to have a different commit message for prod and for dev if you want (so fix and chore for us). So if parser 2.0 is released, then generator gets fix commit with bump of parser 2.0. And it is up to the generator tests to fail if 2.0 is breaking something

from .github.

did some research on GH search as I could not understand why my search query finds only 3 repos while there should be 5. Luckily found answer -> forks are not indexed unless they have many starts aka they are pupular. Which makes sense, as we do not want to do automated bump in forks.

😌

so now just proper tests left

from .github.

Now I will work on adding bump workflow to all other repos that need it:

• generator
• generator-hooks
• generator-filters
• asyncapi-node
• converter
• raml schema parser
• avro schema parser
• openapi schema parser

lot's of work 😓 but it will pay off

from .github.

Something that I liked from some actions is that they default the GH token to GITHUB_TOKEN. We could do something similar defaulting to GH_TOKEN (asyncapi-bot) and, if it's not found, try GITHUB_TOKEN (github-actions).

from .github.

@fmvilas unfortunately not something we can do here. This action pushes changes to other repositories and default GITHUB_TOKEN has right only to the repo it is running in. So in case of this action, or the global one I created recently, you need token of a user that has write permissions to a repo

from .github.

Then let's default to GITHUB_TOKEN, which is present everywhere. Is it possible? Or am I misunderstanding something?

from .github.

no, I probably explained it wrong.

This action will have to clone another, dependent repo, bump version in package.json and push the change to upstream, to separate branch, and then create PR. It will work like dependabot. This means it needs token different that the default one

I cannot default to GITHUB_TOKEN because it is always token that points to github-action bot. I could default to GH_TOKEN or TOKEN, but I don't think it is good to guess how could users' name tokens of their bots

from .github.

Oh, I see! Thanks for explaining 👍

from .github.

Main logic is ready and works when I test it with my test organization https://github.com/derberg/org-projects-dependency-manager

now just need to put some effort in good amount of tests as this action can not only do good but also bad

from .github.

ok, it looks like it worked like a charm in the parser. Have a look at

• https://github.com/asyncapi/parser-js/runs/1530107272?check_suite_focus=true
• asyncapi/parser-js#208

I also created an issue to work later on the generation of dependency diagram as first we need to know what we want to generate and then we can define the structure of data that we need -> derberg/npm-dependency-manager-for-your-github-org#1

from .github.

actually, it did not work exactly as expected, the bump started on GitHub Release creation, but the package was not yet on npm, this is why the bump of parser 1.2.0 happened and not 1.3.0. I'll check what timeouts need to be added to the workflow

from .github.

done repos:

• asyncapi/spec-json-schemas#27
• asyncapi/generator#459
• asyncapi/raml-dt-schema-parser#20
• asyncapi/openapi-schema-parser#18
• asyncapi/avro-schema-parser#24
• asyncapi/generator-filters#17
• asyncapi/generator-hooks#11
• https://github.com/asyncapi/converter-js/pull/14/files
• asyncapi/generator-react-sdk#5

from .github.

Is there anything missing?

@derberg Just a question, how are major versions handled? Didnt see any information about that, or I missed it somewhere?

from .github.

I consider this topic as closed, all PRs merged, action works like a charm

from .github.