Automate syncing master into dev after each release
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 52/100
Research direction
Start by reviewing CONTRIBUTING.md, the branch-sync requirement in #69, and the repository's existing workflow configuration. Trace how pushes to master and workflow_dispatch should compare master with dev, then verify the no-op case and the sync pull request's branch name, label, merge guidance, and CI path. Done means the workflow reliably opens the requested PR only when dev is behind.
Written by the indexing model from the issue text.
Description
Summary
Automate syncing master back into dev, so the two branches cannot silently drift apart
again.
Why
dev fell 14 commits behind master and nobody noticed until a downstream build broke.
Repaired in #68, but the underlying cause is unaddressed: the sync is a manual step that is
easy to forget after a release.
What was missing from dev was not incidental — the whole WebARKitVideoLuma module, the KPM
matcher determinism fix (2c9f630), the logging work and the 1.7.6 version bump.
The consequence is worse than untidy history. CONTRIBUTING.md tells contributors to branch
from dev and open PRs against dev. While dev was stale, a branch taken from it could not
be built by consumers at all:
emcc: error: .../WebARKit/WebARKitVideoLuma.cpp: No such file or directory
WebARKitVideoLuma.cpp lives at WebARKit/WebARKitVideoLuma.cpp on master, which is where
jsartoolkitNFT's tools/makem.js expects it; on
the stale dev it was absent. So the documented contribution flow produced unbuildable
branches — hit while opening #67.
Why not a ruleset instead
A branch ruleset can restrict merge methods, but only unconditionally per branch. The rule that
matters here is conditional on the kind of PR:
PR into dev |
correct method |
|---|---|
master -> dev sync |
merge commit |
| ordinary feature or fix | squash is fine |
Restricting dev to merge-commits-only would force every feature PR into a merge commit too,
contradicting the squash convention. Leaving squash enabled leaves the bad case reachable. A
ruleset is wrong about half the time, so it is not the right instrument.
More to the point: the drift did not happen because anyone chose the wrong merge button. It
happened because nobody ran the sync for 14 commits. Automation addresses that; enforcement
does not.
Proposed approach
A workflow that opens a master -> dev pull request whenever master moves ahead:
- Trigger on push to
master(andworkflow_dispatchfor manual runs). - Exit quietly when
devis already up to date, so it is silent in the normal case. - Open a PR from a
chore/sync-dev-<sha>branch intodevwhen it is not. - Label it so it is recognisable, and state in the body that it must be merged with a
merge commit, not squashed or rebased — see #69.
Opening a PR rather than pushing directly keeps CI in the loop and leaves a human to resolve
conflicts on the rare occasion there are any. #68 merged with none.
An alternative worth considering is auto-merging the sync PR when it is conflict-free and CI is
green, leaving a human only for the conflicting case.
Notes
- #69 documents the merge-commit requirement for branch-sync PRs. This issue is about removing
the need to remember it. - Worth checking whether
webarkit-testingand other consumers trackdevormaster, since
that affects how urgent a staledevactually is.
- Dominant language
- C++
- Stars
- 21
- Forks
- 8
- Avg merge
- 7h 30m
- Merged PRs (30d)
- 25
Getting set up
- No Dockerfile or Docker Compose file
- No pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from webarkit/WebARKitLib
-
Sync workflow: handle a conflicting sync branch with no open PR, and PRs the workflow did not openOpenCI enhancement
Difficulty 3/5 Half a day Newbie friendliness 45/100
webarkit/WebARKitLib#92 ·
Maintainers usually reply within 1 day
-
Optical tracker: frames without a marker run detection twice since the #53 full-resolution retryOpenC/C++ code enhancement
Difficulty 4/5 3-5 days Newbie friendliness 35/100
webarkit/WebARKitLib#91 ·
Maintainers usually reply within 1 day
-
C/C++ code enhancement
Difficulty 4/5 3-5 days Newbie friendliness 25/100
webarkit/WebARKitLib#87 ·
Maintainers usually reply within 1 day
-
Real-world pose scale from a physical marker width at init (ArtoolkitX-style), not the _pattern.size/2 pixel centre offsetMay be free again @kalwalt claimed this 103 days ago, and no pull request is open. Openenhancement question
webarkit/WebARKitLib#62 · 1 assignee ·
Maintainers usually reply within 1 day
-
Difficulty 5/5 Over a week Newbie friendliness 20/100
webarkit/WebARKitLib#48 ·
Maintainers usually reply within 1 day
All issues in webarkit/WebARKitLib
Similar issues
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
Maintainers usually reply within 1 day
-
Mac mini M6 (16 GB): Q2_0 streaming works - measured 11.7->27.2 tok/s + arena fix for sub-32 GB MacsOpen
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
Maintainers usually reply within 1 day
-
champion good first issue remake source/qq
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
metasequoiaime/msime-windows#1025 ·
Maintainers usually reply within 1 day
-
backlog bug
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
EchoTools/nevr-runtime#653 ·
Maintainers usually reply within 1 day
-
`--fail-require-skip` never fires: run_tests.py searches stdout, but the unittest binary writes the skip summary to stderrPossibly taken A pull request linked to this issue is open or already merged. Open
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Maintainers usually reply within 1 day