General guidelines
This article outlines how to propose a change to
sixtyfour
. For more information about contributing to this,
and other WILDS projects, please see the WILDS Contributing
Guide.
Fixing typos/docs changes
You can fix typos, spelling mistakes, or grammatical errors in the documentation directly using the GitHub web interface, as long as the changes are made in the source file.
Bigger changes
If you want to make a bigger change, it’s a good idea to first file an issue and make sure someone from the team agrees that it’s needed.
If you’ve found a bug, please file an issue that illustrates the bug with a minimal reproducible example using reprex.
Note that this package has a Makefile
in the root of the
repository - see the targets in the Makefile
for various
package maintenance tasks.
Git Flow
This package follows Git
Flow. In brief, there’s two main branches: main
and
dev
. main
is considered to be more or less
“production-ready” and at any given time should be associated with the
most recent release. The dev
branch has the most recent
state of the in development code for the package. When dev
reaches a state where we’re ready for a release, we’ll merge
dev
back to main
and cut a release. When you
make a feature branch, please branch off of dev
.
Pull request process
- Fork the package and clone onto your computer
- Checkout the
dev
branch - Create a Git branch off of
dev
for your pull request (PR) - Make your changes, commit to git, and then create a pull request
against
dev
.- The title of your PR should briefly describe the change.
- The body of your PR should contain
Fixes #issue-number
.
- For user-facing changes, add a bullet to the
NEWS.md
file.
Code style
- New/edited code should follow the WILDS style guide.
Testing
We strive to have all tests that do HTTP requests do so against resources that are not actual AWS accounts given the drawbacks with using real accounts, e.g., setting them up can be difficult at some organizations; forgotten resources can be expensive; accidentally making unwated changes to an account, etc.
We use two tools to replace real AWS accounts: Minio, Localstack.
Minio
We use Minio for testing two sets of functions in this package for interacting with S3:
- tests in
test-buckets.R
- tests in
test-files.R
Local
sixtyfour
tests that use Minio will just be skipped if
you don’t have Minio running.
To use Minio, first install it for your platform: MacOS, Windows, Linux.
Next, start Minio. Within this package is a make target
minio_start
for starting Minio locally; it should only work
on Linux and MacOS platforms.
Upon starting Minio it will display URLs for both the Minio API and WebUI - and your username/password to login to the WebUI. You can open up the WebUI as a nice visual dashboard of what’s going on.
GitHub Actions
The R-CMD-check
workflow in
.github/workflows/
includes spinning up Minio for running
unit tests - but only on Linux; tests that require Minio are skipped on
MacOS and WIndows platforms on GitHub Actions.
Minio Details
The following information (collapsed) is for those who want to know more about the minio setup, and may want to tweak it or add minio setup to other tests.
Expand for details
-
tests/testthat/helper-minio.R
has helper functions for Minio.bucket_delete
andbuckets_empty
make it easier to do cleanup in tests. Theminio_available
function is to be used insideskip_if_not
to skip the tests in the file if Minio is not available, like:skip_if_not(minio_available(), "Minio Not Available")
- At the top of any file that uses Minio, setup the interfaces to Minio like:
Sys.setenv(AWS_PROFILE = "minio")
- And unset at the bottom of the file to cleanup:
Sys.unsetenv("AWS_PROFILE")
Internally we grab client objects for paws
and
s3fs
as needed and use AWS_PROFILE
env var to
toggle on/off using Minio.
For Minio we use the default credentials:
- Access key id:
minioadmin
(override with env varMINIO_USER
) - Secret access key:
minioadmin
(override with env varMINIO_PWD
) - Endpoint:
http://127.0.0.1:9000
(override with env varMINIO_ENDPOINT
)
You can override these defaults by setting the env vars above to your own values.
Localstack
We use Localstack for testing some functions in this package:
- tests in
test-groups.R
- tests in
test-policies.R
- tests in
test-roles.R
- tests in
test-s3.R
- tests in
test-secrets_manager.R
- tests in
test-users.R
- tests in
test-vpc.R
Local
sixtyfour
tests that use Localstack will just be skipped
if you don’t have Localstack running.
To use Localstack, first install it for your platform https://docs.localstack.cloud/getting-started/installation/.
Next, start Localstack. Within this package is a make target
localstack_start
for starting Localstack locally. That make
target should only work on Linux and MacOS platforms.
For a GUI interface to the locally running localstack you can install the Desktop client - which isn’t very good - at https://docs.localstack.cloud/getting-started/installation/#localstack-desktop. Better yet, login to the cloud Localstack site and you can interface with your locally running Localstack in the better interface there. Login at https://app.localstack.cloud/.
GitHub Actions
The R-CMD-check
workflow in
.github/workflows/
includes spinning up Localstack for
running unit tests - but only on Linux; tests that require Localstack
are skipped on MacOS and WIndows platforms on GitHub Actions.
Localstack Details
The following (collapsed) bullets list information for those who want to know more about the Localstack setup, and that may want to tweak it or add Localstack setup to other tests.
Expand for details
-
tests/testthat/helper-localstack.R
has helper functions for Localstack. Thelocalstack_available
function is to be used insideskip_if_not
to skip the tests in the file if Localstack is not available, like:skip_if_not(localstack_available(), "Localstack Not Available")
- At the top of any file that uses Localstack, setup the interfaces to Localstack like:
Sys.setenv(AWS_PROFILE = "localstack")
- And unset at the bottom of the file to cleanup:
Sys.unsetenv("AWS_PROFILE")
Internally we grab client objects for paws
and
s3fs
as needed and use AWS_PROFILE
env var to
toggle on/off using Localstack.
For Localstack we use the default credentials:
- Access key id:
NOTAREALKEY
(override with env varLOCALSTACK_KEY
) - Secret access key:
AREALLYFAKETOKEN
(override with env varLOCALSTACK_SECRET
) - Endpoint:
http://localhost.localstack.cloud:4566
(override with env varLOCALSTACK_ENDPOINT
)
You can override these defaults by setting the env vars above to your own values.
Code of Conduct
Please note that this project is released with a Contributor Code of Conduct. By contributing to this project you agree to abide by its terms.