Create/update an issue per feature #7
Conversation
foolip
force-pushed
the
issue-per-feature
branch
from
956766e to
0b0a11f
Compare
Co-authored-by: Patrick Brosset <[email protected]>
|
I think this would work now. @captainbrosset care to review? In particular the issue template is important, and isn't very good yet. |
Co-authored-by: François Daoust <[email protected]>
|
Seeing that it would "only" create ~300 issues I went ahead and triggered this in https://github.com/web-platform-dx/developer-signals/actions/runs/16290425578/job/45998890724 to shake out additional bugs. Issues are being created now. |
|
I got the escaping wrong, deleting some code should fix that... |
This should fix < in issue titles
|
Detecting open issues doesn't reliably work, debugging... Update: fixed |
| } | ||
| } | ||
|
|
||
| // Sort features by earliest release date in any browser, using subsequent shipping |
There was a problem hiding this comment.
Why do we need to sort the features exactly? I'm not sure I follow.
There was a problem hiding this comment.
It's not strictly necessary, but I wanted the issue list to be roughly chronological, with older features being created first, similar to what would happen if this script had been running for years already.
Now that the issues are already seeded I could just delete this. WDYT?
There was a problem hiding this comment.
I guess it's fine to keep the code now that it exists. Sorting logic is not fantastically straightforward, but shouldn't need to change much, if at all.
Co-authored-by: Patrick Brosset <[email protected]>
Co-authored-by: Patrick Brosset <[email protected]>
|
I've set up publishing to GitHub pages now. https://github.com/web-platform-dx/developer-signals/actions/runs/17132686614 failed, but I think it would work if the setup is on main, I tried the same setup in https://github.com/foolip/spec-reactions first. |
There was a problem hiding this comment.
One typo on a varianble name, but this looks good to me.
It seems orthogonal to this PR but I remember we discussed tracking the evolution of the number of reactions over time. The published JSON manifest file will only have the total number of +1s. Would tracking involve merging different versions of the manifest file over time?
| // | ||
| // TODO: Migrate to https://github.com/web-platform-dx/web-features-mappings/ | ||
| // once that is published to NPM. | ||
| const postitionsUrl = |
There was a problem hiding this comment.
| const postitionsUrl = | |
| const positionsUrl = |
| const resp = await fetch(postitionsUrl); | ||
| if (!resp.ok) { | ||
| throw new Error(`Failed to fetch ${postitionsUrl}: ${resp.statusText}`); | ||
| } |
There was a problem hiding this comment.
| const resp = await fetch(postitionsUrl); | |
| if (!resp.ok) { | |
| throw new Error(`Failed to fetch ${postitionsUrl}: ${resp.statusText}`); | |
| } | |
| const resp = await fetch(positionsUrl); | |
| if (!resp.ok) { | |
| throw new Error(`Failed to fetch ${positionsUrl}: ${resp.statusText}`); | |
| } |
| } | ||
| } | ||
|
|
||
| // Sort features by earliest release date in any browser, using subsequent shipping |
There was a problem hiding this comment.
I guess it's fine to keep the code now that it exists. Sorting logic is not fantastically straightforward, but shouldn't need to change much, if at all.
No description provided.