WIP: Automate deployment of pull requests #15

Draft
ansv7779 wants to merge 6 commits from branch-deploy into develop

6 Commits

Author SHA1 Message Date
be46db9528 Remove Shibboleth (SAML) log in
All checks were successful
Deploy to branch.dsv.su.se / deploy (pull_request) Successful in 4m1s
Build and test / build-and-test (push) Successful in 7m10s
Tomcat/Apache integration for SAML will populate the ServletRequest#getRemoteUser with an empty string rather than null when not authenticated. This confuses Spring Security to think the user is authenticated but with an empty string as the principal name. This causes problems further down the line in Spring Security since an empty principal is not accepted.

To get around this we simply remove the SAML integration and rely solely on OAuth 2.0 for log in. An alternative would be to apply a servlet filter beforehand that would send null if the string is empty. But that has the downside of having different authentication mechanism for production and development. By using only OAuth 2.0 everywhere it works the same, and it is easier to troubleshoot.
2024-11-21 23:01:04 +01:00
ccb18fbc5a Speed up Docker build by properly caching all dependencies in an earlier layer
Forcing --offline while building to discover dependencies that have not been cached.
2024-11-21 23:01:04 +01:00
927d24e45a Attempt at automatic deployment 2024-11-21 23:01:04 +01:00
faec676de9 Switch to Spring Security for authentication and allow local OAuth 2 log in
Instead of storing the current user in the Wicket session, let Spring Security handle it. The CurrentUser implementation has been changed to look it up from there instead of the Wicket session.

Also enable, in addition to Shibboleth (pre-authenticated remote user), OAuth 2 login which removes the need for the locally modified web.xml with a faked remote user. The Docker Compose file has been updated to run a OAuth 2 container for this type of login.
2024-11-21 23:01:04 +01:00
6aa06ecc1d Squash all database migrations
All checks were successful
Build and test / build-and-test (push) Successful in 6m38s
There are migrations that do not work on an empty database (372) and many others that give deprecated warnings that will stop working in the future.

This change runs all the migrations (with a fixed 372) and then takes a dump of the result and uses that as a new baseline migration for Flyway. Baselines are meant for existing databases where Flyway is introduced so to fool Flyway into baselining we change the table Flyway uses from the old schema_version to the new flyway_schema_history (default).

The new baseline has no warnings and no invalid migrations and can be run on both empty databases and existing ones.

While Flyway has support for this type of a new baseline (or state scripts), that is only available in the paid editions and not the community version.
2024-11-21 23:01:04 +01:00
5476fc82ea Do not create duplicate templates
Was caused by a refactor that removed the credits used to differentiate project types while master and one-year master were the same. Now it is different types and the credits were no longer needed and got removed.
2024-11-21 22:55:52 +01:00