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

feat: update Modelina to support AsyncAPI 2.5, Python and Rust generator #374

Merged
merged 28 commits into from
Jan 16, 2023

Conversation

jonaslagoni
Copy link
Member

@jonaslagoni jonaslagoni commented Oct 17, 2022

Description
This PR adds support for AsyncAPI 2.5, Python and Rust model generation by upgrading the modelina dependency.

@jonaslagoni jonaslagoni marked this pull request as draft October 17, 2022 16:36
@jonaslagoni jonaslagoni changed the title feat: add support for AsyncAPI 2.5 and Python generator feat: add support for AsyncAPI 2.5, Python and Rust generator Oct 17, 2022
@jonaslagoni jonaslagoni marked this pull request as ready for review October 17, 2022 16:48
Copy link
Member

@derberg derberg left a 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",
Copy link
Member

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?

Copy link
Member Author

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

Copy link
Member

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 🤔

Copy link
Member

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

Copy link
Member Author

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

Copy link
Member

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 from nodejs topic. Then we can have autobump topic. Only repos with this topic would get updates, and modelina 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)

cc @KhudaDad414 @magicmatatjahu @smoya

Copy link
Member Author

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?

Copy link
Member

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?

Copy link
Member Author

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 🤷

@jonaslagoni jonaslagoni requested a review from derberg November 16, 2022 11:38
@jonaslagoni
Copy link
Member Author

Any reason why the tests are broken? 🧐 I don't see any of the changes I did which affected them, do you?

@derberg
Copy link
Member

derberg commented Nov 16, 2022

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

@jonaslagoni
Copy link
Member Author

@derberg but the problems with the tests are oclif errors?

@derberg
Copy link
Member

derberg commented Nov 21, 2022

@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 "lockfileVersion": 1 and version from master is "lockfileVersion": 2. I recommend taking latest package-lock.json from master, and run installation on local again but with npm > 6

@derberg
Copy link
Member

derberg commented Nov 22, 2022

finally different errors 🚀 😄
have a look, sometimes message do not match reality. Also try fixing by switching from toMatch instead of toEqual. I saw @magicmatatjahu did it in one of his PRs. Probably because of switch to jest

@derberg
Copy link
Member

derberg commented Dec 1, 2022

@jonaslagoni you need help?

@jonaslagoni
Copy link
Member Author

@derberg I need a better way to integrate with the old parser 😅 See asyncapi/modelina#1050 and asyncapi/parser-js#687

@jonaslagoni
Copy link
Member Author

jonaslagoni commented Jan 11, 2023

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

@jonaslagoni jonaslagoni changed the title feat: add support for AsyncAPI 2.5, Python and Rust generator feat: update Modleina to support AsyncAPI 2.5, Python and Rust generator Jan 12, 2023
@jonaslagoni jonaslagoni changed the title feat: update Modleina to support AsyncAPI 2.5, Python and Rust generator feat: update Modelina to support AsyncAPI 2.5, Python and Rust generator Jan 12, 2023
@@ -17,7 +17,6 @@ node_modules
asyncapi.json
asyncapi.yaml
asyncapi.yml
/test/docs
Copy link
Member Author

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.

Comment on lines +31 to +51
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();
}
);
});
Copy link
Member Author

@jonaslagoni jonaslagoni Jan 12, 2023

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.

@jonaslagoni
Copy link
Member Author

PR is ready for final review 🙂

Souvikns
Souvikns previously approved these changes Jan 12, 2023
derberg
derberg previously approved these changes Jan 12, 2023
@jonaslagoni jonaslagoni dismissed stale reviews from derberg and Souvikns via 6456797 January 13, 2023 09:02
@jonaslagoni
Copy link
Member Author

Fixed the conflict from master, feel free to merge whenever you have the reviews you think is needed 🙂

@sonarqubecloud
Copy link

Kudos, SonarCloud Quality Gate passed!    Quality Gate passed

Bug A 0 Bugs
Vulnerability A 0 Vulnerabilities
Security Hotspot A 0 Security Hotspots
Code Smell A 0 Code Smells

No Coverage information No Coverage information
0.0% 0.0% Duplication

@derberg
Copy link
Member

derberg commented Jan 16, 2023

/rtm

@asyncapi-bot asyncapi-bot merged commit e4a5a1d into asyncapi:master Jan 16, 2023
@jonaslagoni jonaslagoni deleted the feature/upgrade_modelina branch January 16, 2023 08:35
@asyncapi-bot
Copy link
Contributor

🎉 This PR is included in version 0.28.0 🎉

The release is available on:

Your semantic-release bot 📦🚀

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants