WIP: Automate deployment of pull requests #15

ansv7779 · 2024-11-06T20:11:20+01:00

ansv7779 commented

2024-11-06 20:11:20 +01:00

Click link and see that system is working. Log in using the principal admin@example.com. Change something in the deployed system. Re-run the action. See that the database has reset.

Major change Added OAuth 2 login so no longer need modified web.xml with filter. Run docker compose up to start the local OAuth 2 authorization server to log in. Use the custom ticket form and enter the username you want to log in as in the "Principal" field.

Squashed all migrations since there are faulty ones that can't be applied to an empty database.

Click link and see that system is working. Log in using the principal `admin@example.com`. Change something in the deployed system. Re-run the action. See that the database has reset. **Major change** Added OAuth 2 login so no longer need modified web.xml with filter. Run `docker compose up` to start the local OAuth 2 authorization server to log in. Use the custom ticket form and enter the username you want to log in as in the "Principal" field. Squashed all migrations since there are faulty ones that can't be applied to an empty database.

ansv7779 added 5 commits 2024-11-06 20:11:20 +01:00

Do not create duplicate templates 72f165e026

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.

Squash all database migrations 316d5c76af

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.

Added missing @Transactional 350fa6de80

In case the user has no profile (first time logging in) it tries to create one.
Since there is no transaction running it fails to save this profile.

Switch to Spring Security for authentication and allow local OAuth 2 log in

Build and test / build-and-test (push) Successful in 6m33s

Details

58c395e495

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.

The "import user from external services upon successful login" has unfortunately been removed. However since there are batch jobs that do this every day this should not be noticeable.

Attempt at automatic deployment

Build and test / build-and-test (push) Successful in 6m46s

Details

Deploy to branch.dsv.su.se / deploy (pull_request) Successful in 4m4s

Details

269bb71f56

gitea-actions commented

2024-11-06 20:15:25 +01:00

First-time contributor

Deployed to https://scipro-branch-deploy.branch.dsv.su.se

ansv7779 force-pushed branch-deploy from 269bb71f56 to a2b06900de

2024-11-06 20:20:56 +01:00

Compare

ansv7779 force-pushed branch-deploy from a2b06900de to a90c94d92b

2024-11-06 20:24:51 +01:00

Compare

ansv7779 force-pushed branch-deploy from a90c94d92b to 493e06c825

2024-11-20 16:52:30 +01:00

Compare

ansv7779 force-pushed branch-deploy from 493e06c825 to 0e37f0299c

2024-11-21 10:55:11 +01:00

Compare

ansv7779 added 1 commit 2024-11-21 13:07:37 +01:00

Remove Shibboleth (SAML) log in

Deploy to branch.dsv.su.se / deploy (pull_request) Successful in 3m53s

Details

Build and test / build-and-test (push) Successful in 7m6s

Details

51d7c88e97

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.

ansv7779 force-pushed branch-deploy from 51d7c88e97 to be46db9528

2024-11-21 23:09:53 +01:00

Compare

ansv7779 referenced this pull request

2024-11-22 22:24:20 +01:00

Squash and fix migrations so they run against an empty schema #24

ansv7779 referenced this pull request

2024-11-26 15:33:39 +01:00

Switch authentication to OAuth 2 #27

tozh4728 referenced this issue from a commit

2024-12-02 10:31:23 +01:00

Squash and fix migrations so they run against an empty schema (#24)