-
-
Notifications
You must be signed in to change notification settings - Fork 195
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
feat: update Modelina to support AsyncAPI 2.5, Python and Rust generator #374
feat: update Modelina to support AsyncAPI 2.5, Python and Rust generator #374
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
you have some conflicts with package-lock and failing tests
package.json
Outdated
@@ -11,7 +11,7 @@ | |||
"@asyncapi/converter": "^1.1.0", | |||
"@asyncapi/diff": "^0.4.0", | |||
"@asyncapi/generator": "^1.9.12", | |||
"@asyncapi/modelina": "^0.59.8", | |||
"@asyncapi/modelina": "^1.0.0-next.22", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
did you adjust modelina release config, so this is not reverted to 0.59.9
with next regular release?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can I adapt the release workflow when it's managed by .github? 🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
oh crap, you are right, it is possible with react component with https://github.com/asyncapi/asyncapi-react/blob/master/.github/workflows/bump.yml#L34 hack in global workflow but only because HTML template only depends on react component.
but cli
needs bumps from other packages, not only modelina
🤔
we need something smarter 🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Opting out modelina
from bump.yml
updates pushed from .github
is the only solution I see I think.
It will require some refactor to https://github.com/asyncapi/.github/blob/master/.github/workflows/global-replicator.yml config.
other than that, I could always add some feature to derberg/npm-dependency-manager-for-your-github-org
but not sure what that could be
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it make sense that derberg/npm-dependency-manager-for-your-github-org
was context depending on the version strategy, and "understand" what to update and what not to? 🤔 I.e. in this case "understand" that because we use a next-generation branch, only updates from that can be used going forward instead of those from master? 🧐
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
in our scenario bump
runs in scope of modelina. When it runs in next
branch scope, it surely can figure that out, that it runs in next
branch, and do something specific. But the problem is when it runs in scope of master
, how will it know to not do anything in dependant projects? in cli
it works on default master branch 🤷🏼
I don't think there is any other solution than:
- have some .bump.config.yml file that you can add to repo, where you can specify what repos should be ignored, and you would store it in master
or
- modify settings of workflow that updates all repos, manage
bump.yml
workflow as separate workflow, independent fromnodejs
topic. Then we can haveautobump
topic. Only repos with this topic would get updates, andmodelina
would be opted out (not only modelina as we have the same case with parser now) from bump workflow updates and could this way have custom settings (like repos to ignore or entire workflow removed from master)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But the problem is when it runs in scope of master, how will it know to not do anything in dependant projects?
Will it not be able to process the dependent project package.json file to determine the current version and see whether it uses a pre-build id or which major version it uses?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
technically possible, but why should it have such functionality?
basing on what condition will it know that RC used in package.json is the last one, and actually main release should be used?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I might be missing some crucial point here, but in the bump workflow, it should be possible to get the new version of the library, and then take the version of the library it tries to bump, and correlate the semver version with each other to know whether to bump it or not.
Of course, this should not automatically update from pre-release to a new major version. Or I guess it can 🤷
# Conflicts: # package-lock.json
# Conflicts: # package-lock.json # package.json
Any reason why the tests are broken? 🧐 I don't see any of the changes I did which affected them, do you? |
@jonaslagoni hard to say really. First time I see such errors. I see you did not make much changes but you did bump modelina to 1.0 release candidate. I dunno how much changed there, but maybe some basic stuff changed that affects the tests? errory types? |
@derberg but the problems with the tests are oclif errors? |
@jonaslagoni when I checkout your branch and install it, I get the same warning related errors. I think it is like this only because of installation of some crappy patch. You installed dependencies using |
# Conflicts: # package-lock.json
finally different errors 🚀 😄 |
@jonaslagoni you need help? |
@derberg I need a better way to integrate with the old parser 😅 See asyncapi/modelina#1050 and asyncapi/parser-js#687 |
I am gonna need some help with the test CI, cause I have no idea why it's failing and I cannot reproduce it locally, any ideas? @derberg Maybe it's related to #374 (comment) 🤔 |
@@ -17,7 +17,6 @@ node_modules | |||
asyncapi.json | |||
asyncapi.yaml | |||
asyncapi.yml | |||
/test/docs |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Because each file is cleaned up in the fromTemplate
test, there is no reason to ignore it, and because one of the tests require that it's not ignored.
describe('git clash', () => { | ||
const pathToOutput = './test/docs/2'; | ||
beforeAll(() => { | ||
fs.mkdirSync(pathToOutput, { recursive: true }); | ||
// Write a random file to trigger that dir has unstaged changes. | ||
fs.writeFileSync(path.join(pathToOutput, 'random.md'), ''); | ||
}); | ||
test | ||
.stderr() | ||
.command([...generalOptions, '--output=./test/docs/2']) | ||
.it( | ||
'should throw error if output folder is in a git repository', | ||
(ctx, done) => { | ||
expect(ctx.stderr).toContain( | ||
'Error: "./test/docs/2" is in a git repository with unstaged changes.' | ||
); | ||
cleanup('./test/docs/2'); | ||
done(); | ||
} | ||
); | ||
}); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I dont quite understand why this worked before, but I guess that's just race conditions in a nutshell 🤷
I refactored the tests so each tests are completely siloed from the other. Furthermore, this test is specifically set up to trigger the error by using an empty unstaged file.
PR is ready for final review 🙂 |
# Conflicts: # package-lock.json
Fixed the conflict from master, feel free to merge whenever you have the reviews you think is needed 🙂 |
Kudos, SonarCloud Quality Gate passed!
|
/rtm |
🎉 This PR is included in version 0.28.0 🎉 The release is available on: Your semantic-release bot 📦🚀 |
Description
This PR adds support for AsyncAPI 2.5, Python and Rust model generation by upgrading the modelina dependency.