Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
derberg opened this issue Dec 2, 2020 · 15 comments
Labels
enhancement New feature or request

Comments

@derberg
Copy link
Member

derberg commented Dec 2, 2020

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

internal-deps-management

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
Copy link
Member

fmvilas commented Dec 2, 2020

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
Copy link
Member Author

derberg commented Dec 2, 2020

@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
Copy link
Member

fmvilas commented Dec 2, 2020

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

@derberg
Copy link
Member Author

derberg commented Dec 2, 2020

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
Copy link
Member

fmvilas commented Dec 2, 2020

Oh, I see! Thanks for explaining 👍

@derberg
Copy link
Member Author

derberg commented Dec 2, 2020

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
Copy link
Member Author

derberg commented Dec 3, 2020

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
Copy link
Member Author

derberg commented Dec 10, 2020

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

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
Copy link
Member Author

derberg commented Dec 10, 2020

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
Copy link
Member Author

derberg commented Dec 10, 2020

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
Copy link
Member Author

derberg commented Dec 11, 2020

@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
Copy link
Member

jonaslagoni commented Dec 11, 2020

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
Copy link
Member Author

derberg commented Dec 11, 2020

@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
Copy link
Member Author

derberg commented Dec 14, 2020

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

@derberg derberg closed this as completed Dec 14, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants