Skip to content
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

Closed
wants to merge 52 commits into from
Closed

Adding a config_automation.yml #435

wants to merge 52 commits into from

Conversation

cansavvy
Copy link
Collaborator

@cansavvy cansavvy commented Feb 8, 2022

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 to yes or no to indicate whether or not they should be on. When changes are made and pushed to config_automation.yml they are automatically incorporated by the manage-gha.yml GHA by it calling and running the scripts/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 in config_automation.yml. It finds the on trigger by where it says TRIGGER-START and TRIGGER-END. It either replaces it with the on trigger (which is from the on-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 to Actions, but they will not be run automatically unless specified as such in the config_automation.yml file.

How on triggers are updated -- maintenance purposes

store-triggers.R will update the current state of the GHA triggers. Normally store-triggers.R doesn't need to be run, but if the on trigger for any of the github actions changes, then store-triggers.R needs to be run to store the new version in the on-triggers.rds. BUT, first all GHA need to be turned on in config_automation.yml before store-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.

@github-actions
Copy link
Contributor

github-actions bot commented Feb 8, 2022

No spelling errors! 🎉
Comment updated at 2022-02-09 with changes from 3502022

@github-actions
Copy link
Contributor

github-actions bot commented Feb 8, 2022

Re-rendered previews from the latest commit:

Updated at 2022-02-09 with changes from 64236f0

@cansavvy
Copy link
Collaborator Author

cansavvy commented Feb 8, 2022

@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.

@carriewright11
Copy link
Member

carriewright11 commented Feb 8, 2022

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

@cansavvy
Copy link
Collaborator Author

cansavvy commented Feb 8, 2022

Thanks for adding to the sync file... I guess we don't need to sync get_spell_errors.R right?

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.

@carriewright11
Copy link
Member

carriewright11 commented Feb 8, 2022

Thanks for adding to the sync file... I guess we don't need to sync get_spell_errors.R right?

I should have put this add in a different PR. Whoops. But actually we should 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 transfer-rendered-files.yml at this point, so you don't need it. - wow I didn't know you could edit other peoples comments :P

@carriewright11
Copy link
Member

thanks @cansavvy ! Also this looks like a great start for the plan we discussed!

@cansavvy
Copy link
Collaborator Author

cansavvy commented Feb 9, 2022

Proposed plan of action for @avahoffman review

  1. Do you have an idea for how to make the set up of on-trigger.rds better? It's pretty shoot yourself in the foot right now.
  2. Give it a review overall and if/when it seems reasonabl we can merge it to staging
  3. Test it out on staging branch -- create some pull requests, play around with turning GHA on and off -- how easy/not easy is it to use? Try to break it while testing.

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!

@cansavvy
Copy link
Collaborator Author

cansavvy commented Feb 9, 2022

Additionally, I need to make delete-preview.ymls trigger tied to render-preview.yml

cansavvy added a commit that referenced this pull request Feb 9, 2022
* Add the polishing changes

* No manage-gha

* No login needed

* Make it simpler for commits and pushes
@@ -0,0 +1,32 @@
# Write on-trigger yaml
# This script stores what the 'on' triggers look like for each github action
Copy link
Collaborator Author

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.

dplyr::filter(basename(gha_file) == gha_files) %>%
dplyr::pull("on_or_off")

if (length(status) == 1) {
Copy link
Collaborator Author

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

Copy link
Collaborator Author

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.

Copy link
Collaborator Author

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.

Copy link
Collaborator Author

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.

@cansavvy
Copy link
Collaborator Author

cansavvy commented Feb 9, 2022

@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.

@cansavvy
Copy link
Collaborator Author

cansavvy commented Feb 9, 2022

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. pyyaml is where I'm going to start.

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.

@avahoffman
Copy link
Contributor

@cansavvy good to know. I'm playing with an alternative approach that might work well right now. Stay tuned!

@cansavvy
Copy link
Collaborator Author

Closing this. We have something better going on on #445 , #448, and #449

@cansavvy cansavvy closed this Feb 10, 2022
@cansavvy cansavvy deleted the cansavvy/main-gha branch February 11, 2022 13:15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants