Warning: This is a WIP
idp-scim-sync
is Apache 2.0 licensed and
accepts contributions via GitHub pull requests. This document outlines
some of the conventions on to make it easier to get your contribution
accepted.
We gratefully welcome improvements to issues and documentation as well as to code.
By contributing to this project you agree to the Developer Certificate of Origin (DCO). This document was created by the Linux Kernel community and is a simple statement that you, as a contributor, have the legal right to make the contribution.
- All contributors to
idp-scim-sync
must sign off each contribution (usually this means each commit).The signature must contain your real name (sorry, no pseudonyms or anonymous contributions). If youruser.name
anduser.email
are configured in your Git config, you can sign your commit automatically withgit commit -s
. - Each commit sign off will be reviewed by the idp-scim-sync maintainer (by taking a look at their email address and Github profile) before merging the contribution.
References:
- https://en.wikipedia.org/wiki/Developer_Certificate_of_Origin#:~:text=The%20Developer%20Certificate%20of%20Origin,Contributor%20License%20Agreement%20(CLA)
- https://developercertificate.org/
- https://probot.github.io/apps/dco/
- https://writing.kemitchell.com/2021/07/02/DCO-Not-CLA.html
If you are entirely new to idp-scim-sync, you might want to take a look at:
- What is the AWS Single Sign-On SCIM implementation?
- AWS Single Sign-On
- Workspace Admin SDK -> Directory API
To get started with developing idp-scim-sync
, you might want to check the following:
- https://go.dev/
- https://github.com/spf13/cobra
- https://github.com/spf13/viper
- AWS SSO SCIM -> Supported API operations
- Workspace Admin SDK -> Directory API -> Go quickstart
- Code Reviews
- Testing Code that depends on google.golang.org/api
- Unit Testing with the AWS SDK for Go V2
- OpenSSF Best Practices Badge Program
- CodeQL documentation
These are generated using gomock project.
For better integration I use go:generate to run gomock
command inside files when mocks are needed
Prerequisites:
make test
Clean up the test output:
make clean
These things will make a PR more likely to be accepted:
- a well-described requirement
- tests for new code
- tests for old code!
- new code and tests follow the conventions in old code and tests
- a good commit message (see below)
- all code must abide Go Code Review Comments
- names should abide What's in a name
- code must build on both Linux and Darwin, via plain
go build
or usingmake build-dist
- code should have appropriate test coverage and tests should be written to work with
go test ./...
ormake test
Try to follow Conventional Commits or Semantic Commit Messages