Create GitHub Action that will handle automated bump of internal AsyncAPI dependencies

[derberg]

Reason/Context

Internal AsyncAPI dependencies are for example a dependency that Generator has to Parser. So we want to automatically bump version of Parser in package.json for Generator, in Generator repo, once Parser is released.

To have best user experience we should not manually maintain dependency tree between repos and use action only in the repository that runs release

Description

How would it work

• you use this action only in the project that should be updated in other projects
• it is part of release workflow, you just trigger it if there was a change in the version of the package

Configuration Options

• Specify GH token
• Specify where package.json is located in case it is not root
• Specify list of repos that would be ignored and not receive update
• Committer details
• commit message for devDependency, so you can always start it with chore
• commit message for dependency, so you can always start it with fix

• we should also expose on output a kind of information about dependency and it dependents. With another action we can push it somewhere, aggregate it from all the repos and have an application that reads it and builds dependency graph of all repos in the organization

[fmvilas]

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).

[derberg]

@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

[fmvilas]

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

[derberg]

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

[fmvilas]

Oh, I see! Thanks for explaining 👍

[derberg]

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

[derberg]

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

[derberg]

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
• ci: add workflow that bumps parser in other asyncapi repos 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

[derberg]

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

[derberg]

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

[derberg]

done repos:

• ci: add workflow that bumps asyncapi/specs in other asyncapi repos spec-json-schemas#27
• ci: add workflow that bumps generator in other asyncapi repos generator#459
• ci: add workflow that bumps parser in other asyncapi repos raml-dt-schema-parser#20
• ci: add workflow that bumps parser in other asyncapi repos openapi-schema-parser#18
• ci: add workflow that bumps parser in other asyncapi repos avro-schema-parser#24
• ci: add automated bump workflow and improve pr testing asyncapi-archived-repos/generator-filters#17
• ci: add automated bump workflow and improve pr testing asyncapi-archived-repos/generator-hooks#11
• https://github.com/asyncapi/converter-js/pull/14/files
• ci: add workflow that bumps sdk in other asyncapi projects generator-react-sdk#5

[derberg]

@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?

[jonaslagoni]

Is there anything missing?

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

[derberg]

@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

[derberg]

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