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

Setup env-loader CI/CD and dev tooling #284

Merged
merged 8 commits into from
Nov 6, 2024
Merged

Conversation

fheinecke
Copy link
Contributor

This PR creates dev and release tooling for the env-loader tool. This reuses tooling that was previously written for the changelog generator. The tooling includes:

  • Makefile with targets for linting, testing, and building for all supported platforms
  • PR testing workflow
  • Release workflow
  • Dev container config files for local development

While the git diff makes this unclear, the only real changes to the files previously under tools/changelog are very slight generalization to remove hard-coded "changelog" values. Same thing with the GHA workflows. The actual logic is the same, just pulled out into reusable workflows with hard-coded, tool-specific values removed.

I've also included a dep update in the PR to avoid filing an additional one, but I can split it out if requested.

@fheinecke fheinecke requested a review from a team as a code owner November 4, 2024 20:46
name: Environment value loader CI

on:
pull_request:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I understand release workflows being separate but for CI can we simplify and just have one workflow that executes all tests? Right now tools may be nicely separated but what if they say use a shared library and it gets modified, this sort of separation will just add headache later. Let's just have a single "unit tests" workflow that runs all Go tests.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right now tools may be nicely separated but what if they say use a shared library and it gets modified, this sort of separation will just add headache later

Can you clarify what kind of issue this will cause? A large portion of this RFD and the structure it introduced was to reduce headaches and problems introduced by coupling projects together.

@fheinecke fheinecke merged commit a6abc83 into main Nov 6, 2024
9 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants