Skip to content

Conversation

@MichaelsJP
Copy link
Member

Pull Request Checklist

  • 1. I have rebased the latest version of the main branch into my feature branch and all conflicts
    have been resolved.
  • 2. I have added information about the change/addition to functionality to the CHANGELOG.md file under the
    [Unreleased] heading.
  • 3. I have documented my code using JDocs tags.
  • 4. I have removed unnecessary commented out code, imports and System.out.println statements.
  • 5. I have written JUnit tests for any new methods/classes and ensured that they pass.
  • 6. I have created API tests for any new functionality exposed to the API.
  • 7. If changes/additions are made to the ors-config.json file, I have added these to the ors config documentation
    along with a short description of what it is for, and documented this in the Pull Request (below).
  • 8. I have built graphs with my code of the Heidelberg.osm.gz file and run the api-tests with all test passing
  • 9. I have referenced the Issue Number in the Pull Request (if the changes were from an issue).
  • 10. For new features or changes involving building of graphs, I have tested on a larger dataset
    (at least Germany), and the graphs build without problems (i.e. no out-of-memory errors).
  • 11. For new features or changes involving the graphbuilding process (i.e. changing encoders, updating the
    importer etc.), I have generated longer distance routes for the affected profiles with different options
    (avoid features, max weight etc.) and compared these with the routes of the same parameters and start/end
    points generated from the current live ORS.
    If there are differences then the reasoning for these MUST be documented in the pull request.
  • 12. I have written in the Pull Request information about the changes made including their intended usage
    and why the change was needed.
  • 13. For changes touching the API documentation, I have tested that the API playground renders correctly.

Fixes # .

Information about the changes

  • Key functionality added:
  • Reason for change:

Examples and reasons for differences between live ORS routes, and those generated from this pull request

Required changes to ors config (if applicable)

@MichaelsJP MichaelsJP changed the title Ci/add reusable workflow environment setup ci: add reusable workflow environment setup Dec 8, 2025
Our workflows are very redundant in many places. It is hard to maintain it. This will abstract the most common code redundancies and have them in one maintainable place. This allows for central version changes and functionality testing.

The following actions are implemented. They will be used in later PRs:

setup-build-environment is the absolute basic environment setup for all workflows. It can set up all necessary environments with simple flags. It also streamlines the actions versions and docker caches.

parse-release-tag is now well encapsulated and testable release tag parsing function.
@MichaelsJP MichaelsJP force-pushed the ci/add-reusable-workflow-environment-setup branch from 376d126 to e053e92 Compare December 8, 2025 09:43
@github-actions github-actions bot added the ci label Dec 8, 2025
@MichaelsJP MichaelsJP changed the title ci: add reusable workflow environment setup ci: Use the new environment setup and streamline sonarcube scan Dec 8, 2025
@MichaelsJP MichaelsJP requested a review from takb December 8, 2025 09:44
@github-actions github-actions bot added ci and removed ci labels Dec 8, 2025
@MichaelsJP MichaelsJP removed the request for review from takb December 8, 2025 09:47
@MichaelsJP MichaelsJP closed this Dec 8, 2025
@MichaelsJP MichaelsJP deleted the ci/add-reusable-workflow-environment-setup branch December 8, 2025 09:49
@sonarqubecloud
Copy link

sonarqubecloud bot commented Dec 8, 2025

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

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant