chore(metrics): init Metrics in app init, cleanup setup code to one b… #1167
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.
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.
Does it happen in other repos? which automatic merge are you referring to?
There was a problem hiding this comment.
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.
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.
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.
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
…e/metrics-cleanup
Avantol13
added
test-apis-dbgapTest
test-apis-centralizedAuth
and removed
test-apis-dbgapTest
labels
| @@ -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.
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.
| 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