Update workflow for new augur clades version#1000
Conversation
jameshadfield
force-pushed
the
new-augur-clades
branch
3 times, most recently
from
a93d52c to
0dbe4df
Compare
|
Rebased and re-tested using the (now released) Augur v22.0.0 Note there is one change here which is to be fixed on Augur's side - the clade coloring entry is now the bottom entry in the (Auspice) dropdown rather than the top. PR for that forthcoming. |
|
CI Failures on conda: CI Failures on Docker: Note that I wrote #1070 specifically because of the error seen on Docker (which you'll also see when running locally) |
jameshadfield
force-pushed
the
new-augur-clades
branch
from
0dbe4df to
43a3f75
Compare
|
Updated to require minimum augur version of 22.0.1 |
jameshadfield
force-pushed
the
new-augur-clades
branch
from
43a3f75 to
21f88a2
Compare
|
Force pushed (with no changes) to trigger a new CI run, now that augur 22.0.1 is available in conda-base |
This updates the workflow to use the new clades interface from augur v22 (see nextstrain/augur#728). In the process we can remove two rules from the workflow. The minimum augur version is bumped to 22.0.1, as that includes a couple of important bug-fixes. If this workflow is run with augur prior to v22, the emerging_lineages rule will error due to unknown arguments. The script add_branch_labels.py is no longer used and thus removed here (as recommended in code review: #1000 (comment)) Note that it contained unused functionality to export spike mutations; if we reinstate this in the future we should update the output format to produce a node-data JSON with a custom branch label to avoid modifying the auspice JSON after export.
jameshadfield
force-pushed
the
new-augur-clades
branch
from
21f88a2 to
322b8a9
Compare
This is a minor aesthetic change which restores the order of the branch labels in Auspice so that clade appears before emerging_lingeage. The change in ordering was introduced by the previous commit as we moved from a custom script to using `augur clades` interface from Augur v22.0.0 The ordering is not specified and cannot be configured, but in practice it is the order of the keys in the dictionary (and which is stable in CPython 3.6, Python 3.7, and most (all?) JS engines).
jameshadfield
force-pushed
the
new-augur-clades
branch
from
322b8a9 to
7b5312e
Compare
2 participants
This updates the workflow to use augur after augur PR nextstrain/augur#728 has been merged. It removes two rules from the workflow.
In the situation where the ncov workflow is not updated but augur is, the pipeline will proceed without error however the 'emerging_lineage' branch label will be missing. (This is because the add_branch_labels.py script is looking for the key 'clade_annotation' which is no longer present.)
In the situation where the ncov workflow is updated but augur is not, rule.emerging_lineages will error due to unknown arguments. You can see this in the failing CI for this PR 😉
The script add_branch_labels.py is no longer used, but not removed here, as it contains logic to export spike mutations as branch labels which may be useful at some point. If we do use this, it would be better to produce an intermediate node-data JSON with a custom branch label to avoid modifying the auspice JSON after export.
Release checklist
If this pull request introduces backward incompatible changes, complete the following steps for a new release of the workflow:
docs/src/reference/change_log.mdin this pull request to document these changes and the new version number.If this pull request introduces new features, complete the following steps:
docs/src/reference/change_log.mdin this pull request to document these changes by the date they were added.