• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Tim Cooke
  • Campbell Ritchie
  • paul wheaton
  • Ron McLeod
  • Devaka Cooray
Sheriffs:
  • Jeanne Boyarsky
  • Liutauras Vilda
  • Paul Clapham
Saloon Keepers:
  • Tim Holloway
  • Carey Brown
  • Piet Souris
Bartenders:

Learning GitHub Actions - Inner loop reuse

 
Ranch Hand
Posts: 72
1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Brent

Do you have any suggestions on how to get better reuse between your inner and outer loops during software development?

Inner loop would be pre-commit checks in your local development environment and outer-loop would be GitHub Actions, in this case. I've experimented with pre-commit and make which can be reused in GitHub Actions, but I'm curious if there are better patterns you may be able to share.

Cheers,
Greg
 
Author
Posts: 11
1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Greg - thanks for the question.

In my 25+ years of experience with inner and outer loops, I can say that I'm more of a fan of using the pull request model as the ultimate gate for changes. I have certainly used pre-commit git hooks (which are hard to enforce across dev teams) and tools like Gerrit (which "capture" the code between the commit and push and allow you to run checks there).

While I would not every attempt to dissuade anyone from having good testing/pre-commit/pre-flight checks, I do think it is important to use a pull request type of model to gate changes.  With GitHub Actions, you can set up required workflows (equivalent of pipeline scripts) to do things like security scans, trial builds, and run tests at multiple levels when a pull request is made. That gives you both powerful "pre-checks" before final merge and a standardized way of enforcing the checks across all changes - as opposed to having to rely on local commit checks only.  As an example, you can look at the list of workflows that are used to validate changes for the "checkout action" at https://github.com/actions/checkout/actions

As well, I've found that I am doing more and more of my changes in the GitHub browser interface or things like GitHub Codespaces which don't really require the same local clone/commit processes.  In fact, if you're viewing a file in GitHub, and click the "." key or change the URL to start with "github.dev" rather than "github.com" you get a browser-based version of VS Code.  In those situations, pre-commit hooks/checks don't really apply so that's another reason I'm a fan of utilizing the GitHub Actions workflows triggered on pull requests as the gating checks.

Hope this helps.
 
Greg Horie
Ranch Hand
Posts: 72
1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Brent

I didn't realize you could use "github.dev" to switch to a browser-based VS Code. I'll have to give that a try.

For my development work I use PRs, so I'll experiment with using more GitHub Actions and fewer pre-commit hooks. I still like the pre-commits for quick checks, but it is more code that you have to maintain.

Thanks for the tips!
reply
    Bookmark Topic Watch Topic
  • New Topic