Review the following guidelines for submitting questions, issues, or changes to this repository. One of the most impactful changes would be examples and documentation.
To contribute to ibmsecurity, please use pull requests on a branch of your own fork.
After [creating your fork on GitHub], you can do:
$ git clone --recursive git@github.com:your-name/ibmsecurity
$ cd ibmsecurity
$ # Recommended: Initialize and activate a Python virtual environment
$ pip install --upgrade pip
$ pip install -e '.[test]' # Install testing dependencies
$ tox run -e lint
$ git checkout -b your-branch-name
# DO SOME CODING HERE
# Add tests under `test/`
$ tox run -e lint,py
$ git add your new files
$ git commit -v
$ git push origin your-branch-name
You will then be able to create a pull request from your commit.
There is no mock code for testing against, unfortunately. So you need a running IBM Verify Access/IBM Identity Verify Access appliance or container to be able to run the tests.
Create a .env file in the root directory of the project, with the details to connect to your IVIA appliance, for instance :
IVIA_ADMIN=admin@local
IVIA_PW=admin
IVIA_HOST=<ip address of lmi>
# IVIA_PORT = 80
IVIA_SECMASTER=sec_master
IVIA_SECMASTER_PW=<password for sec_master>Optionally, you can configure a proxy (http_proxy or https_proxy)
IVIA_HTTPS_PROXY=http://localhost:3128
IVIA_HTTP_PROXY=http://127.0.0.1:3128Although there is no full test set (yet), you should prepare a test for any changes or new code that is added. You can run specific tests, filtered on the name of the test.
For instance, to run all tests against the Webseal configuration, run:
pytest -k _web_ -s -rPAutomated tests will be run against all PRs, to run checks locally before pushing commits, use tox.
Fix any issues
If you encounter an issue, have a question or want to suggest an enhancement, you are welcome to submit a request. Before that, please search for similar issues. It's possible somebody has encountered this issue already.
If you want to contribute to the repository, here's a quick guide:
- Fork the repository
- Develop and test your code changes:
- Follow the coding style as documented above.
- Please add one or more tests to validate your changes.
- Make sure everything builds/tests cleanly.
- Commit your changes. Add a descriptive prefix to commits. The list allowed is as below:
featfor featuresfixfor bug fixesrevertfor reversing a changedocsfor documentation and examplesstylefor formatting and other related changesrefactoris self-explanatorytestfor test case changesbuildfor build changesautogenfor any auto-generated code or documentationsecurityfor any security fixes and enhancementscifor changes to continuous integrationchoreis self-explanatory
- Push to your fork and submit a pull request to the
mainbranch. Include the tests executed in the pull request.
Each source file must include a license header for the Apache Software License 2.0. Using the SPDX format is the simplest approach. e.g.
/*
Copyright IBM Corp. All Rights Reserved.
SPDX-License-Identifier: Apache-2.0
*/
In accordance to the approach used by the Linux® Kernel community and described in the Developer's Certificate of Origin 1.1 (DCO), we request that each contributor signs off their change by adding a Signed-off-by line to each commit message.
Here is an example Signed-off-by line, which indicates that the submitter accepts the DCO:
Signed-off-by: John Doe <john.doe@example.com>
You can include this automatically when you commit a change to your local git repository using the following command:
git commit -s