GHA Newbie here: what are all these 3rd-party actions that people are using? How complicated is your build / deployment pipeline that you need a bunch of premade special steps for it?
Surely it's simple: use a base OS container, install packages, run a makefile.
For deployment, how can you use pre-made deployment scripts? Either your environment is bespoke VPS/on-prem, In which case you write your deployment scripts anyway, or you use k8s and have no deployment scripts. Where is this strange middleground where you can re-use random third party bits?
Can't speak for everyone, but workflows can get pretty crazy in my personal experience.
For example the last place I worked had a mono repo that contained ~80 micro services spread across three separate languages. It also contained ~200 shared libraries used by different subsets of the services. Running the entire unit-test suite took about 1.5 hours. Running the integration tests for everything took about 8 hours and the burn-in behavioral QA tests took 3-4 days. Waiting for the entire test suite to run for every PR is untenable so you start adding complexity to trim down what gets run only to what is relevant to the changes.
A PR would run the unit tests only for the services that had changes included in it. Library changes would also trigger the unit tests in any of the services that depended on them. Some sets of unit tests still required services, some didn't. We used an in-house action that mapped the files changed to relevant sets of tests to run.
When we updated a software dependency, we had a separate in-house action that would locate all the services that use that dependency and attempt to set them attempt to set them to the same value, running the subsequent tests.
Dependency caching is a big one and frankly Github's built-in cacheing is so incredibly buggy and inconsistent it can't be relied on... So third party there. It keeps going on:
- Associating bug reports to recent changes
- Ensuring PRs and issues meet your compliance obligations around change management
- Ensuring changes touching specific lines of code have specific reviewers (CODEOWNERS is not always sufficiently granular)
- Running vulnerability scans
- Running a suite of different static and lint checkers
- Building, tagging, and uploading container artifacts for testing and review
- Building and publishing documentation and initial set of release notes for editing and review
- Notifying out to slack when new releases are available
- Validating certain kinds of changes are backported to supported versions
Special branches might trigger additional processes like running a set of upgrade and regression tests from previously deployed versions (especially if you're supporting long-term support releases).
That was a bit off the top of my head. Splitting that from a mono-repo doesn't simplify the problem unfortunately it just moves it.
Surely it's simple: use a base OS container, install packages, run a makefile.
For deployment, how can you use pre-made deployment scripts? Either your environment is bespoke VPS/on-prem, In which case you write your deployment scripts anyway, or you use k8s and have no deployment scripts. Where is this strange middleground where you can re-use random third party bits?