Sorry for the delay.
Idpy meeting 20 February 2024
Attendees: Johan W., Johan L., Alex Perez-Mendez, Shayna, Ivan, Roland, Mikael Frykholm, Björn Mattsson
0 - Agenda bash
1 - Demo
2 - Project review
a. General -
Roland has been writing a description of the steps required to stand up a federation using his software, and how to add another entity to the federation, different topologies of the federation, and so on. He has a first cut available.
Björn Mattsson mentioned that they have been using this document to try and get a federation up on the SWAMID side (I'm sorry, I missed the specific project name this was for), building a Docker image to run the different parts. They will provide feedback to Roland about using it this way.
Can also be used in Core AAI, educational use case
AARC people are also looking at this to use cross-infra exchange of tokens. OIDC but using the federations to build trust. A client can talk to a resource server from another domain because that server talks to an issuer that is part of a federated network, which trusts the issuer of the client.
github actions added to workflow (continuous integration): clones the repo, sets up python and anything else needed, and runs linting with pre-commit hooks to include flake8
also runs basic yaml and whitespace cleanup
developer can install precommit hook - then any got commit command will do flake8 checks as project has defined
same checks get run by github actions if developer forgets or chooses to not install pre-commit
currently flake8 config is in tox.ini and setup.cfg - that should be stripped and flake8 config should be put in its own file
goal: to get everything that was done in travis into github actions (including syntax checks, style checks using isort and python black, test phases/pytest, deploy to pypi, etc). Would like to also add automated container image updates for SATOSA eventually. No credentials need to be hardcoded when interfacing with pypi (when we get to that).
There should be discussion on whether to merge things in pieces or in one big PR. It is possible to bypass pre-commit hooks and github actions will only put a "this doesn't work" badge on commits that don't the match flake8 checks, for this particular PR. Next the isort and python black would probably be best to do in one PR that touches all files, but may affect other PRs that are out there (ask developers to rebase?).
e. Any other project (pyFF, djangosaml2, pyMDOC-CBOR, etc)
2 - AOB