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

A more native GitHub Actions workflow would be nice #170

Open
bensheldon opened this issue Mar 27, 2024 · 2 comments
Open

A more native GitHub Actions workflow would be nice #170

bensheldon opened this issue Mar 27, 2024 · 2 comments
Labels
help wanted Extra attention is needed

Comments

@bensheldon
Copy link
Contributor

The GitHub Actions workflow for testing Trilogy would likely be faster and more maintainable if it used more GitHub Actions-native functionality. This would mean for the workflow to set up different services through GitHub Actions and use ruby/setup-ruby to run tests within a matrix.

The current GitHub Actions workflow uses Docker in the script/cibuild to build and run docker containers within the CI environment, which is slow and not the best use of GitHub Actions:

trilogy/script/cibuild

Lines 53 to 57 in b11647a

docker-compose rm -s -f -v
output_fold "Pull cache image..." docker-compose pull app || true
output_fold "Bootstrapping container..." docker-compose build
output_fold "Running tests..." docker-compose run --rm app
output_fold "Pushing cache image..." docker-compose push app || true # Don't fail if push fails

@bensheldon bensheldon added the help wanted Extra attention is needed label Mar 27, 2024
@ngan
Copy link
Contributor

ngan commented Apr 8, 2024

@bensheldon @composerinteralia Is there a specific reason we're testing trilogy specifically on debian? Is ubuntu good enough?

And is there a reason for this specific permutation?

- mysql: "5.7"
distribution: "debian:buster"
ruby: "2.7.8"

@bensheldon
Copy link
Contributor Author

I think that is trying to bracket with the oldest supported versions. I do think there may be some applications still using debian:buster, so unless it's a pain to keep that, I think we should keep it another year or 2 (or till we do feel pain, because I imagine coming back to this issue 4 years from now 👋)

nickborromeo added a commit to nickborromeo/trilogy that referenced this issue May 20, 2024
In the `CONTRIBUTING.md` it says

> To shorten the development loop you can:
>
> a) run trilogy tests locally with: make test
> b) run ruby binding tests with cd contrib/ruby, bundle exec rake test. It's possible to run a test single example by passing a TESTOPTS environment variable like so: TESTOPTS=-n/test_packet_size_greater_than_trilogy_max_packet_len/.

When you follow these instructions, it will fail if you do not have a
`test` database created. This change adds tasks the following tasks:

- `db:create`
- `db:drop`
- `db:clean`

When running the ruby binding tests, it will run the `db:clean` task to
drop the test database first (if it exists) and creates it.

I think it will also be helpful to have a similar task in the `Makefile`
so that `make test` can setup the DB if the user chooses not to use the
docker approach. However, I am not sure how to do this 🤔

It might also be useful to push forward with
trilogy-libraries#170 as we can
pontentially move away from Docker for the CI builds.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

3 participants
@ngan @bensheldon and others