Comments (10)
I guess the key would be to add a standard operating procedure to tag anything submitted to a journal - then one could re-run with the tag to get the word files for word's compare documents feature.
Great idea. It's never too late to create a tag and the tag would enable dispatching the workflow for the past version of the manuscript.
from rootstock.
That looks like a good way to do it. I believe that is similar to what the second paragraph of the build readme is describing: https://github.com/manubot/rootstock/tree/main/build.
However, the typical Manubot user does not know to navigate to the build instructions to see documentation about environment variables and how to enable DOCX output. We could link to these instructions from the usage, add more support for environment variables, or do something else.
from rootstock.
I do think that's what the second paragraph describes, but I didn't find that the BUILD_DOCX variable was actually used without adding the env section to manubot. Perhaps there was a change in behavior?
from rootstock.
The env
section does need to be added to the workflow file, which is what the linked GitHub doc is trying to describe. If that is unclear, we should rewrite the rootstock build instructions paragraph.
I tested that in a demo manuscript, and it generated a docx output gitter-lab/bds-srop-demo-manuscript@5d54318
Where you trying to control the environment variables for the project somewhere else outside of the workflow file?
from rootstock.
Ahh - I was trying to control the environment variables using the configuration variables for a repository or organization:
This line uses those (if set): https://github.com/greenelab/optimizer-manuscript/pull/21/files#diff-fa87c4632db9a7181e39293e05358b7eb56c42e17024cc863f2b1eab2523cff0R3
from rootstock.
Got it. I'd say we need a docs improvement to
- point to the build instructions from usage so this is easier to find in the first place
- better explain how to set the
env
variable in the workflow and distinguish between that and the configuration variables in a repository
from rootstock.
Do you want a PR that would use those variables if they are set but not have an impact otherwise, or should we leave that as an exercise for the user?
from rootstock.
I'm fairly indifferent. My main preference is that there is one primary way of changing environment variables when doing things with Manubot instead of splitting it between modifying workflow yaml files and repo settings. We are somewhat oriented toward modifying yaml files based on the AI revision workflow variables and spellcheck variable in the main workflow.
Let's wait for @dhimmel's thoughts too before making a PR.
from rootstock.
Okay so I think @cgreene added BUILD_DOCX as a repository action variable in the settings at https://github.com/<USER>/<REPO>/settings/variables/actions
. Was it the following GitHub menu you used at /settings/variables/actions/new
?
It looks like we'd have to access those in the workflow using the vars
context rather than the env
context (env context is made available to the shell and therefore would trigger BUILD_DOCX properly).
@cgreene are you aware of the one time builds using workflow dispatch (as shown below)? Do you want a DOCX just for some builds that can be manually triggered or all builds?
I have a slight preference for keeping persistent configuration in code rather than in repo settings (secrets being the obvious exception). If this feature generates more interest we could reconsider?
from rootstock.
I did add them that way. I am aware of that feature but have experienced challenges in the past when folks didn't generate word docs at each stage & journals wanted word comparisons to show review changes. I guess the key would be to add a standard operating procedure to tag anything submitted to a journal - then one could re-run with the tag to get the word files for word's compare documents feature.
from rootstock.
Related Issues (20)
- Review Commons / Template Compatibility HOT 1
- Deploy built DOCX to Github pages HOT 4
- load_bibliography: error reading 'content/manual-references.json' HOT 6
- no output saved in a forked manuscript HOT 4
- Editing Demo Manuboat HOT 1
- deployment timeout HOT 6
- Issues with local build command HOT 1
- Upgrade manubot to fix pubmed API calls. HOT 6
- Images are not shown in Word (docx) HOT 13
- Contributor Roles Taxonomy HOT 3
- AI workflow cannot create PR HOT 3
- best practice for integrating pandas-generated tables into manubot docs HOT 5
- Error: The process '/usr/share/miniconda3/condabin/conda' failed with exit code 1 HOT 5
- Change the name of the generated output pdf and .docx files HOT 4
- Convert repository to GitHub Template HOT 4
- Run failed: pages build and deployment HOT 1
- setup failing HOT 2
- docx fails to open HOT 4
- AppVeyor CI builds fail due to spellcheck dependencies HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from rootstock.