-
Notifications
You must be signed in to change notification settings - Fork 2
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
fix: adds passage-version header to all api calls #69
Conversation
7b06041
to
7038d71
Compare
7038d71
to
6ff10d2
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry, I take back the approval. Can you also add the changes to the CHANGELOG?
I know we are waiting to release, but we should still make it easy on ourselves and make a note of the unreleased changes so we don't have to look back to see what has changed.
Would writing unreleased changes to our changelog be preferable to using the conventional commit messages to aggregate the changes when were ready to release? I wasn't sure if writing unreleased changes to the log could be confusing to anyone reading it |
I typically lean more towards an Unreleased section. Us not having a reliable, agreed upon commit message standard, also supports this. Having an Unreleased section is a fairly common practice. You can see an example here. Unreleased sections can help devs know what is coming and make updates to CHANGELOGS easier when we aren't using something like beachball. |
added 74fff14 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Deleted by accident?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
no, .env
should never be committed to a repo. it also opens it up to human error of updating the .env to run tests and accidentally committing the secrets since it's already indexed.
i considered a .env.example
but it's really only used for testing, which isn't in a friendly state for an open-source contributor to run anyways. so i adjusted the test setup to look for the file just in case, but otherwise just grab from the environment.
we do plan on updating the tests (and moving them around a bit) to make it friendlier to run by anyone.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
that being said, i could still add a .env.example
, though we plan on removing the need for it within this initiative
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Up to you. If we have a plan for removal we might be fine. I would just be concerned if Tamara or anyone else worked on the php repo and didn't have an example.
Description
Adds a missing header to requests for tracking the package version.
It looks like OpenAPITools/openapi-generator doesn't expose setting custom headers in the configuration OpenAPITools/openapi-generator#11431, so added a code mod function in the generator to set the additional header code.
Not bumping the version since we have a few more things coming down the pipe we can bundle.
Type of change
Testing
Checklist before approving (including SDK updates)
composer.json
file.CHANGELOG.md
has been updated.Checklist after merging