Add DACPAC action test to PR check

[zijchen]

Looks like we only test the SQL action and not the DACPAC action right now. Added a test for this in the workflow.

DACPAC action should deploy a database with 1 table, and the SQLCMD action should verify it and cleanup afterwards.

[kisantia]

does the database get deleted after the test is done?

[zijchen]

Not currently. I looked into dropping it but because this action runs in parallel on Linux and Windows, I ran into race conditions occasionally when either SqlPackage or SQLCMD hasn't finished and the DB is already dropped by the other run.

I'm not sure what's the best way to cleanup here. Maybe we can add a scheduled job to delete the DB at midnight or something.

[kisantia]

Is it possible for the database name to be different for Linux and Windows? Otherwise a scheduled job sounds good! It would be good to clean up the database so the subscription doesn't get charged for it when it isn't being used and it's a small dacpac being deployed anyway.

[zijchen]

Added test DB name as an env variable. Also added a cleanup step to drop the DB. The cleanup step has to be separate because it needs connection to master DB.

[zijchen]

After merging with master branch, PR check fails because #73 changed the target to pull-request-target which uses the yml definition from master branch, but with sources from the PR branch (no idea why that is). However earlier runs succeed (see deployment history above) so this change should not cause regression.

[dzsquared]

After merging with master branch, PR check fails because #73 changed the target to pull-request-target which uses the yml definition from master branch, but with sources from the PR branch (no idea why that is). However earlier runs succeed (see deployment history above) so this change should not cause regression.

ah my apologies, I didn't realize this change impacts the yml action definition used by the run, but that makes sense. We can potentially revert that change, although it means all tests for PRs from external forks will fail because they won't have access to the secrets needed. I'll investigate further.

[zijchen]

After merging with master branch, PR check fails because #73 changed the target to pull-request-target which uses the yml definition from master branch, but with sources from the PR branch (no idea why that is). However earlier runs succeed (see deployment history above) so this change should not cause regression.

ah my apologies, I didn't realize this change impacts the yml action definition used by the run, but that makes sense. We can potentially revert that change, although it means all tests for PRs from external forks will fail because they won't have access to the secrets needed. I'll investigate further.

I think it's fine. Maybe after all my PRs that will change the yaml definition (this one and #65) we can reimplement #73. Thoughts?

[github-actions]

This PR is idle because it has been open for 14 days with no activity.