CI pipeline for AWBW

[lenikadali]

As a project, we would like to have a CI pipeline that in no particular order:

1. • Is powered by GitHub actions
2. • Has dependency audits (tracked by Add dependency audits to AWBW #75)
3. • Has security analysis [run] (done in Add a better CI pipeline with security scans. #110)
4. • Has linters/style checks [run] (being done in feat: add shopify rubocop #78)
5. • Runs tests (done in Add a better CI pipeline with security scans. #110)
6. • Runs code coverage checks (done in Add code coverage #85)
7. • Publishes artifacts/reports generated by various health check tools for main builds somewhere (so we can keep on eye on what is going on)
8. • Runs the tests in an environment as similar to production as possible (e.g. if CD results in Docker images being deployed then try to run the tests inside of a similar Docker image)

The list above is the North Star we are heading towards and is NOT meant to be achieved in one PR. This issue is meant to track general decisions that we make along the way, with the sub-issues from or related to the above items handling more implementation specific discussion.

Next implementation steps here currently mean looking at the workflows of either Human Essentials or Homeward Tails as they seem to be the most mature Ruby For Good (RFG) projects in this area and mirror that for AWBW. We are doing this to remain in alignment with what other RFG projects so that we are able to leverage the collective experience and expertise, rather than spending (potentially) many development cycles doing things from scratch.

P.S: During creation of sub-issues, crosscheck against Upgrade and Stuff to Do #3 which has overlap with this issue, so that nothing gets accidentally missed.

[lenikadali]

From the Slack discussion regarding this

Just so you know, the codebase is going to fail just about every static analysis gate you add to CI.
Do you have a recommendation for how you want to layer CI incrementally?

One thought I have regarding this is to add the pipeline as is and then comment out what we cannot/will not use. Alongside this, we should create issues for the different things that need to be fixed/added to allow us to use the full CI setup.

What do you think @carlost?

[carlost]

add the pipeline as is

@lenikadali, add the HE or HT workflows as is, comment just about everything out, and then just uncomment things as we are able to add them?

Is the advantage of this treated the commented out workflow as a "TODO", and sort of boxing us in to the existing HE/HT workflows so we don't accidentally diverge as we tackle this issue?

[lenikadali]

add the pipeline as is

@lenikadali, add the HE or HT workflows as is, comment just about everything out, and then just uncomment things as we are able to add them?

Yes please 😇

Is the advantage of this treated the commented out workflow as a "TODO", and sort of boxing us in to the existing HE/HT workflows so we don't accidentally diverge as we tackle this issue?

Exactly. The premise is that if we do diverge, it will be intentional and we will have a commit message indicating why and/or a pull request documenting the decisions made.

[lenikadali]

Update: as per this comment here and here, #75 is blocked by #48, #49, #50 and #51.

[lenikadali]

Update: as per this comment here and here, #75 is blocked by #48, #49, #50 and #51.

#75 was merged with the intention for Rails upgrades to be added at a later stage as mentioned here.

• Publishes artifacts/reports generated by various health check tools for main builds somewhere (so we can keep on eye on what is going on)
• Runs the tests in an environment as similar to production as possible (e.g. if CD results in Docker images being deployed then try to run the tests inside of a similar Docker image)

Not sure if the last two are covered by #85 and #110 or they'll need to be done in a separate PR.

[maebeale]

@lenikadali what are the next steps for CI we need?

[lenikadali]

what are the next steps for CI we need?

The items below are what are tentatively left:

• Has linters/style checks [run] (being done in feat: add shopify rubocop #78)
• Publishes artifacts/reports generated by various health check tools for main builds somewhere (so we can keep on eye on what is going on)
• Runs the tests in an environment as similar to production as possible (e.g. if CD results in Docker images being deployed then try to run the tests inside of a similar Docker image)

@carlost would you say the PRs #85 and #110 meet the criteria for what you're looking for for the last two items?
Also not sure if you're following feat: add shopify rubocop #78 which seems to be doing the linting but doesn't yet add rubocop-rails-omakase as proposed in Upgrade and Stuff to Do #3.

[maebeale]

cc @johnpaulashenfelter