Do not modify openapi-gen generated files by pre-commits#51755
Do not modify openapi-gen generated files by pre-commits#51755potiuk merged 1 commit intoapache:mainfrom
Conversation
The openeop-gen files do not follow our formatting and whitespace expectations - which means that our linting rules and whitespace pre-commit might complain and mofify them after they are generated. But we definitely do not want it and, hey - they are generated so we should just skip them whenever we do linting or whitespace correction.
|
Cool! This will make contributing much smoother🙌 |
Backport failed to create: v3-0-test. View the failure log Run details
You can attempt to backport this manually by running: cherry_picker 2c92125 v3-0-testThis should apply the commit to the v3-0-test branch and leave the commit in conflict state marking After you have resolved the conflicts, you can continue the backport process by running: cherry_picker --continue |
Let me know if you have any more problems with it :) |
…pache#51755) The openeop-gen files do not follow our formatting and whitespace expectations - which means that our linting rules and whitespace pre-commit might complain and mofify them after they are generated. But we definitely do not want it and, hey - they are generated so we should just skip them whenever we do linting or whitespace correction. (cherry picked from commit 2c92125) Co-authored-by: Jarek Potiuk <jarek@potiuk.com>
|
Cool! Thanks! Tested with my other PR and can confirm the pre-commit glitch if fixed! |
…pache#51755) The openeop-gen files do not follow our formatting and whitespace expectations - which means that our linting rules and whitespace pre-commit might complain and mofify them after they are generated. But we definitely do not want it and, hey - they are generated so we should just skip them whenever we do linting or whitespace correction. (cherry picked from commit 2c92125) Co-authored-by: Jarek Potiuk <jarek@potiuk.com>
…51755) (#51757) The openeop-gen files do not follow our formatting and whitespace expectations - which means that our linting rules and whitespace pre-commit might complain and mofify them after they are generated. But we definitely do not want it and, hey - they are generated so we should just skip them whenever we do linting or whitespace correction. (cherry picked from commit 2c92125)
pierrejeambrun
left a comment
There was a problem hiding this comment.
It's still code that we read to contribute to the UI (Understand functions inputs and ouputs, which endpoint is call under the hood etc...)
I think it makes it harder to understand. (but I understand the change).
…reduce bundle size (#51735) * Feat(i18n): Move translation files to public, use i18next-http-backend * Adopted i18next-http-backend * Fix(i18n): Update locales directory path to public for translation files * Fix(i18n): Update static file path for translation locales * Fix(i18n): Update translation config file path * Fix(i18n): Update ESLint configuration to include jsonc-parser * Fix(i18n): Update ESLint file patterns and add 'components' to namespaces * Fix(i18n): Initialize i18n(en) in DagCard tests * chore: enforce consistent array type syntax per @typescript-eslint rule * Revert "chore: enforce consistent array type syntax per @typescript-eslint rule" This reverts commit d218738. * Fix(i18n): Ignore i18n locale files in ESLint TypeScript rules * Fix(tests): Remove unused imports and clean up test setup * Apply pre-commit formatting to openapi-gen/ files as per #51755 * Fix(eslint): Update i18n and TypeScript rules configuration * Apply ESLint and i18nRule * Mov Arabic and French translations to public * Fix: Update translation file paths to public directory * Moved i18n doc and completeness checker script from public to dev/i18n * fix(i18n): i18n policy document translation completeness check command
The openeop-gen files do not follow our formatting and whitespace expectations - which means that our linting rules and whitespace pre-commit might complain and mofify them after they are generated. But we definitely do not want it and, hey - they are generated so we should just skip them whenever we do linting or whitespace correction.
…reduce bundle size (apache#51735) * Feat(i18n): Move translation files to public, use i18next-http-backend * Adopted i18next-http-backend * Fix(i18n): Update locales directory path to public for translation files * Fix(i18n): Update static file path for translation locales * Fix(i18n): Update translation config file path * Fix(i18n): Update ESLint configuration to include jsonc-parser * Fix(i18n): Update ESLint file patterns and add 'components' to namespaces * Fix(i18n): Initialize i18n(en) in DagCard tests * chore: enforce consistent array type syntax per @typescript-eslint rule * Revert "chore: enforce consistent array type syntax per @typescript-eslint rule" This reverts commit d218738. * Fix(i18n): Ignore i18n locale files in ESLint TypeScript rules * Fix(tests): Remove unused imports and clean up test setup * Apply pre-commit formatting to openapi-gen/ files as per apache#51755 * Fix(eslint): Update i18n and TypeScript rules configuration * Apply ESLint and i18nRule * Mov Arabic and French translations to public * Fix: Update translation file paths to public directory * Moved i18n doc and completeness checker script from public to dev/i18n * fix(i18n): i18n policy document translation completeness check command
The openeop-gen files do not follow our formatting and whitespace expectations - which means that our linting rules and whitespace pre-commit might complain and mofify them after they are generated.
But we definitely do not want it and, hey - they are generated so we should just skip them whenever we do linting or whitespace correction.
^ Add meaningful description above
Read the Pull Request Guidelines for more information.
In case of fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
In case of a new dependency, check compliance with the ASF 3rd Party License Policy.
In case of backwards incompatible changes please leave a note in a newsfragment file, named
{pr_number}.significant.rstor{issue_number}.significant.rst, in airflow-core/newsfragments.