FUSETOOLS2-2201: Testing with productized versions of Camel

[pospisilf]

Pull Request informations

Rebase & Merge default requirements

1. Green build for main branch
2. Wait 24 hours after PR creation
3. Green job for PR
4. Approved PR

PR labels default process

• READY_FOR_REVIEW → REVIEW_DONE → READY_FOR_MERGE

Tests

• Are there Unit tests?
• Are there Integration tests?
• Do we need a new UI test?

PR workflow progress

1. Tagged with relevant PR labels
2. Green job for PR
3. PR was created more than 24 hours ago or All committers approved it
4. Green main branch build

[apupier]

so cool to have tests with productized version
it would be convenient to have the camel version used visible in the log in some ways (console.log? the name of the tests ?) https://github.com/camel-tooling/camel-lsp-client-vscode/actions/runs/7395686841/job/20119333839?pr=1611 It will help to ensure that we are really testing with another version and when investigating a log to be sure which version is used.

[pospisilf]

so cool to have tests with productized version it would be convenient to have the camel version used visible in the log in some ways (console.log? the name of the tests ?) https://github.com/camel-tooling/camel-lsp-client-vscode/actions/runs/7395686841/job/20119333839?pr=1611 It will help to ensure that we are really testing with another version and when investigating a log to be sure which version is used.

The used version is included in the job's name for clarity, and there is a check implemented in '00_set.camel.version.test.ts'. This check ensures that the used version aligns with the required version, which is exported as an environmental variable.
There's not a way (if I know) to check, that server configuration was accepted and applied so all we can check is value inside settings.

Using console.log() could potentially reduce the readability of the test result log. Although I have the option to add a step in the 'productized.yaml' pipeline to echo the global variable value. What do you think?

[apupier]

so cool to have tests with productized version it would be convenient to have the camel version used visible in the log in some ways (console.log? the name of the tests ?) https://github.com/camel-tooling/camel-lsp-client-vscode/actions/runs/7395686841/job/20119333839?pr=1611 It will help to ensure that we are really testing with another version and when investigating a log to be sure which version is used.

The used version is included in the job's name for clarity, and there is a check implemented in '00_set.camel.version.test.ts'. This check ensures that the used version aligns with the required version, which is exported as an environmental variable. There's not a way (if I know) to check, that server configuration was accepted and applied so all we can check is value inside settings.

Using console.log() could potentially reduce the readability of the test result log. Although I have the option to add a step in the 'productized.yaml' pipeline to echo the global variable value. What do you think?

I would like to see it directly in the log when playing the test suite even locally. Consequently, another step in the GitHub Actions won't cover this use case.
Given that GitHub UI is cropping job names, I missed it. We can see it when going directly to the job itself as title. I will try to report issues to improve the GitHub UI.

Maybe providing a name of test for 00_set.camel.version.test.ts making it clear which version is used could be a good place.

[pospisilf]

so cool to have tests with productized version it would be convenient to have the camel version used visible in the log in some ways (console.log? the name of the tests ?) https://github.com/camel-tooling/camel-lsp-client-vscode/actions/runs/7395686841/job/20119333839?pr=1611 It will help to ensure that we are really testing with another version and when investigating a log to be sure which version is used.

The used version is included in the job's name for clarity, and there is a check implemented in '00_set.camel.version.test.ts'. This check ensures that the used version aligns with the required version, which is exported as an environmental variable. There's not a way (if I know) to check, that server configuration was accepted and applied so all we can check is value inside settings.
Using console.log() could potentially reduce the readability of the test result log. Although I have the option to add a step in the 'productized.yaml' pipeline to echo the global variable value. What do you think?

I would like to see it directly in the log when playing the test suite even locally. Consequently, another step in the GitHub Actions won't cover this use case. Given that GitHub UI is cropping job names, I missed it. We can see it when going directly to the job itself as title. I will try to report issues to improve the GitHub UI.

Maybe providing a name of test for 00_set.camel.version.test.ts making it clear which version is used could be a good place.

Implemented.

[djelinek]

so cool to have tests with productized version it would be convenient to have the camel version used visible in the log in some ways (console.log? the name of the tests ?) https://github.com/camel-tooling/camel-lsp-client-vscode/actions/runs/7395686841/job/20119333839?pr=1611 It will help to ensure that we are really testing with another version and when investigating a log to be sure which version is used.

The used version is included in the job's name for clarity, and there is a check implemented in '00_set.camel.version.test.ts'. This check ensures that the used version aligns with the required version, which is exported as an environmental variable. There's not a way (if I know) to check, that server configuration was accepted and applied so all we can check is value inside settings.
Using console.log() could potentially reduce the readability of the test result log. Although I have the option to add a step in the 'productized.yaml' pipeline to echo the global variable value. What do you think?

I would like to see it directly in the log when playing the test suite even locally. Consequently, another step in the GitHub Actions won't cover this use case. Given that GitHub UI is cropping job names, I missed it. We can see it when going directly to the job itself as title. I will try to report issues to improve the GitHub UI.

Maybe providing a name of test for 00_set.camel.version.test.ts making it clear which version is used could be a good place.

@apupier is this something you were looking for? cc @pospisilf

[apupier]

@apupier is this something you were looking for? cc @pospisilf

this is nice for version matrix on GitHub action.
Current state of teh PR is fine I think. We can improve in another iteration. I already have some other suggestions/questions that would delay this PR potentially too much.

[djelinek]

could you please investigate option how to set this property directly in setting.json using filesystem, not using UI?

[djelinek]

@pospisilf I have pushed here one commit with some suggestions to make this approach more "clear"

[djelinek]

no need of await if setUserSettingsDirectly is using sync methods

[djelinek]

no need to use async function returning promise

[sonarqubecloud]

Quality Gate passed

Kudos, no new issues were introduced!

0 New issues
0 Security Hotspots
No data about Coverage
0.0% Duplication on New Code

See analysis details on SonarCloud

[pospisilf]

bigger improvements were made, requesting new reviews