Open Healthcare Network

Open Healthcare Network

Open Healthcare Network(OHC) is an open-source platform that helps governments, hospitals, and innovators build connected healthcare systems faster, safer, and at national scale.

Since
6 years

2,357 days

Total Contributors
1,411

All time

Total Activities
746
19%

Last 30 days

Active Contributors
40
18%

Last 30 days

Activity Trend

Daily activity over the last 30 days

746activities in the last 32 days
1,265 total points
020406080100120Jul 18Jul 23Jul 28Aug 2Aug 7Aug 12Aug 17
Activity Breakdown

Distribution by type (30 days)

746activities
PR Reviewed20527%
Commit Created15220%
Commented13318%
PR Opened11616%
PR Merged7310%
Issue Opened304%
Issue Closed233%
Issue Assigned142%

Our Community

1,411 contributors building together

Meet everyone
RIAMABMOARJABONIPRNAYAROVIJAGIEEKENASOSHVIACCEPRKHRISN4AADGA
1381
Recent Activity
View leaderboard
AM
Amjith TitusPushed commit to main·Fix pre-steps: survive Actions' bash -e; JIRA recovery via _edge/tenant_info (#153) Item 1 (highest severity): GitHub Actions invokes run: steps as `bash -e {0}`, so errexit is inherited — `set -uo pipefail` does NOT clear it, only an explicit `set +e` does. The KEY extraction pipeline (grep exits 1 on branches without ENG-nnn) therefore killed the "never fails" JIRA step before its no_ticket fallback could run, hard-failing the agent job for every non-ENG-branch PR (observed in run 32017183079 on PR #152). Fix: explicit `set +e` in the JIRA and lint steps with a comment citing the run, `|| true` on the grep pipeline as belt-and-braces, and an audit of all pre-steps (the resolve and skill-move steps stay deliberately strict). Reproduced locally under `bash -e`: main's version exits 1, this version exits 0 and writes the marker. Item 2: the two-URL rule is now empirically confirmed (scoped API tokens are ignored entirely on *.atlassian.net — anonymous and authenticated requests return identical status codes). Replace the accessible-resources probe (OAuth-Bearer-only; returns 401 uniformly for no-auth/bogus-basic/bogus-bearer, so its 401 says nothing about credentials) with the public, unauthenticated GET <site>/_edge/tenant_info for cloudId discovery, and auto-retry via https://api.atlassian.com/ex/jira/<cloudId>. Remove the now unused .github/scripts/jira_sites.py. Item 3: carry forward the hedged diagnostics from orphaned commit c75b882 (pushed after the #152 squash-merge), now decisive where the evidence allows: when the configured host is *.atlassian.net, the marker recommends the ex/jira form outright; arms stay hedged only where JIRA's 404-for-unviewable behaviour makes causes genuinely indistinguishable. README: add the _edge/tenant_info cloudId discovery command. Recompiled with gh-aw v0.86.2 (0 errors, 0 warnings). Co-authored-by: Copilot App <[email protected]>
+2
AM
Amjith TitusPushed commit to main·Fix analytics-review on workflow_dispatch: pass resolved PR context to the agent (#152) * Fix analytics-review on workflow_dispatch: pass resolved PR context to the agent Dry-run 32015295640 (PR #146) went green end-to-end after the v0.86.2 recompile, but the agent posted nothing: the resolve pre-step's AW_PR_NUMBER/AW_HEAD_REF land in step env only, which never reaches the agent sandbox, and on workflow_dispatch the event payload has no PR object. The agent concluded "no associated pull request ... nothing to review" and noop'd. Fix 1: the resolve step (now id: resolve_pr) also writes step outputs and /tmp/gh-aw/context/run-context.md — the context dir is the one channel proven to reach the agent (it read jira-ticket.md in the same run). The prompt body names run-context.md as the source of truth for PR identity, treats a dispatch run with a resolved PR as a normal review, and reserves noop for runs where no PR resolves at all. (${{ steps.* }} interpolation into the body cannot work: the prompt is rendered in the activation job, the steps run in the agent job.) Fix 2: the same run showed "JIRA returned HTTP 404 for ENG-909" — ambiguous, since JIRA answers 404 for missing ticket, missing project permission, AND bad credentials. On any non-200 the step now probes /rest/api/3/myself and writes an auth diagnosis into the marker (credentials rejected vs authenticated-but-cannot-see vs unreachable), reporting HTTP codes only, never credential values. Still never fails the job. Co-authored-by: Copilot App <[email protected]> * JIRA step: support scoped Atlassian tokens (accessible-resources probe + auto-recovery) Root cause of the ENG-909 404: JIRA_API_TOKEN is a scoped Atlassian API token, and scoped tokens must target https://api.atlassian.com/ex/jira/<cloudId> instead of https://<site>.atlassian.net. Atlassian answers 404 (not 403) when a scoped token hits the site-host form, which mimics a missing issue. - Replace the /rest/api/3/myself probe (not callable with granular read:issue scopes -> would false-report valid credentials as broken) with GET https://api.atlassian.com/oauth/token/accessible-resources, which works for both token types and returns each site's cloudId. - Auto-recovery: when the issue fetch fails and the probe can resolve a cloudId (configured URL matches a site, cloudId embedded in an ex/jira URL, or single-site token), retry via the scoped-token endpoint - so either token type works with either JIRA_BASE_URL form. - Self-diagnosing markers on hard failure: credentials rejected (401/403, mentions <=365-day scoped-token expiry), base URL matches none of the token's sites (lists reachable site URLs + cloudIds and the exact value to set), ticket not visible/nonexistent (tried both endpoints), or api.atlassian.com unreachable. HTTP codes, site URLs and cloudIds only; never credential values. - Comments fetch now uses the possibly-recovered base URL. - README: JIRA_BASE_URL form guidance per token type. - New helper .github/scripts/jira_sites.py (cloud-id resolution + site summary; always exits 0). All six failure/recovery branches exercised locally against a mock Atlassian server using the step script extracted verbatim from the workflow; every path exits 0 and writes the marker. Co-authored-by: Copilot App <[email protected]> --------- Co-authored-by: Copilot App <[email protected]>
+2

Leaderboard

See who's leading this week, month, and year.

People

Browse all contributors and their profiles.

Badges

Explore achievements and milestones earned.