-
Notifications
You must be signed in to change notification settings - Fork 48
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
chore(metrics): init Metrics in app init, cleanup setup code to one b… #1167
base: master
Are you sure you want to change the base?
Conversation
…ash script, begin migration of common code to library
Pull Request Test Coverage Report for Build 10201086602Details
💛 - Coveralls |
# push will run on every pushed commit to any branch (so this will rerun the tests | ||
# once a branch gets merged to main in addition to any new commits on any branch) | ||
on: push | ||
|
||
name: CI | ||
on: | ||
push: | ||
pull_request: | ||
types: [opened, reopened] |
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.
There can be edge cases where the "automatic merge" messes something up, and the CI succeeds on the "branch run", but fails on the "PR run". In that case you have to update your branch manually and fix the conflict that git didn't see. It has happened to me a handful of times, not sure it's worth running the CI twice on every PR, but 🤷♀️
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.
Does it happen in other repos? which automatic merge are you referring to?
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.
it can happen in any repo
i can't find documentation about it but this is my understanding from what i observed:
when 2 checks run (for push and for PR) they're not necessarily running on the same code. The "push" check runs on the branch's code, and the "PR" check runs on the code that would be on master after merging the PR. If there are any changes on master that aren't on the branch, it performs a merge automatically and runs the CI on that. It's the same code that would end up on master if you choose to merge without updating your branch first - git/github finds no conflict and merges. Occasionally it does it wrong, and it can be caught by the "PR" CI check
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.
We should be protected against people merging without first updating their branch, at which point the push should run again. I do remember issues in the past vaguely... but I can't find any documentation in GH Actions that leads me to believe it's necessary to have both of these. Unless you have a strong opinion, I would rather not run everything twice and just get feedback on the code on main
when the branch-creator merges it in and pushes those commits.
@pytest.fixture(scope="function") | ||
def disable_metrics_app(app): | ||
""" | ||
temporarily disable metrics on the session-scoped app for this function |
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.
i'm wondering if we should do the opposite... 🤔 set ENABLE_PROMETHEUS_METRICS
to false in the tests by default and only enable metrics on the tests that need them?
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.
well, I think it's more likely that we'll have this on for our deployments, so I actually like that it's on for unrelated tests, making sure whatever we add for metrics doesn't accidentally break something existing
Co-authored-by: Pauline Ribeyre <4224001+paulineribeyre@users.noreply.github.com>
…e/metrics-cleanup
@@ -41,7 +41,7 @@ RUN poetry config virtualenvs.create false \ | |||
COPY . /$appname | |||
COPY ./deployment/uwsgi/uwsgi.ini /etc/uwsgi/uwsgi.ini | |||
COPY ./deployment/uwsgi/wsgi.py /$appname/wsgi.py | |||
COPY clear_prometheus_multiproc /$appname/clear_prometheus_multiproc | |||
COPY ./deployment/scripts/metrics/setup_prometheus /$appname/setup_prometheus |
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.
i think we can delete this file now https://github.com/uc-cdis/fence/blob/7b0aa60/clear_prometheus_multiproc
doing nothing. This is the behavior when metrics are disabled. Why? So application code | ||
doesn't have to check, it always tries to log a metric. | ||
prometheus_dir (str): Directory to use when setting PROMETHEUS_MULTIPROC_DIR env var (which prometheus requires | ||
for multiprocess metrics collection). Note that this the prometheus client is very |
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.
for multiprocess metrics collection). Note that this the prometheus client is very | |
for multiprocess metrics collection). Note that the prometheus client is very |
…ash script, begin migration of common code to library
New Features
Breaking Changes
Bug Fixes
Improvements
Dependency updates
Deployment changes