-
Notifications
You must be signed in to change notification settings - Fork 14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Adding a config_automation.yml #435
Conversation
No spelling errors! 🎉 |
Re-rendered previews from the latest commit:
Updated at 2022-02-09 with changes from 64236f0 |
@avahoffman Do you want to see what you think about the general concept of this? It's not 100% completed, but it is mostly there. |
Thanks for adding to the sync file... I guess we don't need to sync get_spell_errors.R right? or git_repo_check.R |
I should have put this add in a different PR. Whoops. But actually we don't want to sync get_spell_errors.R so I'll add that. |
what about the repo check... I noticed that got deleted from the OTTR Web repo That's only used in |
thanks @cansavvy ! Also this looks like a great start for the plan we discussed! |
Proposed plan of action for @avahoffman review
If steps 1 - 3 go well and we address any bugs we find, then lets merge to main and test with a couple PRs, then make a new release and ship it out! |
Additionally, I need to make |
* Add the polishing changes * No manage-gha * No login needed * Make it simpler for commits and pushes
scripts/store-triggers.R
Outdated
@@ -0,0 +1,32 @@ | |||
# Write on-trigger yaml | |||
# This script stores what the 'on' triggers look like for each github action |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is the bad script that stores whatever is in the current version of the gha which requires you to turn all the github actions ON before running this.
scripts/employ-gha-switches.R
Outdated
dplyr::filter(basename(gha_file) == gha_files) %>% | ||
dplyr::pull("on_or_off") | ||
|
||
if (length(status) == 1) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's also bad that the trigger gets overwritten whether or not there is a change specified in config_automation.yml
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think my next idea for this, and for the other problem is what if we store a yaml of all the triggers. (.github/triggers.yml
)
So for example:
check-quizzes:
status: on
on: <What the trigger for on looks like>
off: <What the trigger for off looks like>
render-bookdown:
status: on
on: < ... >
off: < ... >
This format would be far easier to manage than an RDS because we can 1) Just change the triggers in this file directly using a text editor and 2) We can use it to check the current status with the previous status so we can avoid overwriting everytime.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My hope is that this kind of yaml would allow the store-triggers.R
script render unnecessary completely and would make everything a lot more streamlined.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
with the latest iteration of this, store-triggers.R
is not obsolete and now you just need to specify things in the gha-triggers.yml
if you want to change the triggers.
@avahoffman I commented on the troublesome places with this PR and also neatened it up a bit. Let me know how it goes. I'll brainstorm a bit myself and comment with any ideas. |
Meanwhile, I'm going to look into Python's handling of yamls, since we suspect it handles yamls better than R, but question is does it handle yamls so much better that we can switch strategies to handle yamls as yamls. Edit: Same story with this -- extra spacing lines and comments are removed if we use pyyaml to write yaml files. So from a quick review, it does not appear that switching to python will allow us to get over this particular problem. |
@cansavvy good to know. I'm playing with an alternative approach that might work well right now. Stay tuned! |
Purpose/implementation Section
What changes are being implemented in this Pull Request?
What the user would need to do:
Change github actions in
config_automation.yml
toyes
orno
to indicate whether or not they should be on. When changes are made and pushed toconfig_automation.yml
they are automatically incorporated by themanage-gha.yml
GHA by it calling and running thescripts/employ-gha-switches.R
script.How scripts/employ-gha-switches.R works
The on triggers for each github action are different for each and they are stored in
on-triggers.rds
scripts/employ-gha-switches.R
reads in all workflows in the directory.github/workflows
. It then reads in the specs from the user inconfig_automation.yml
. It finds the on trigger by where it saysTRIGGER-START
andTRIGGER-END
. It either replaces it with theon
trigger (which is from theon-triggers.rds
) for that particular gha OR it puts a manual dispatch trigger if its been specified to be turned off. This means all github actions can always be manually triggered by going toActions
, but they will not be run automatically unless specified as such in theconfig_automation.yml
file.How on triggers are updated -- maintenance purposes
store-triggers.R
will update the current state of the GHA triggers. Normallystore-triggers.R
doesn't need to be run, but if theon
trigger for any of the github actions changes, thenstore-triggers.R
needs to be run to store the new version in theon-triggers.rds
. BUT, first all GHA need to be turned on inconfig_automation.yml
beforestore-triggers.R
can be run.Reorganization of Coursera as its own GHA render
***Note that I've also separated out render-coursera out into its own github actions so this is easier to manage! So now there's a separate yml for each bookdown, Leanpub, and Coursera. Bookdown happens first, which then triggers the Coursera render, which then triggers the Leanpub render.