Skip to content

Integration tests with GPG signature do not work on forks #175

@josecelano

Description

@josecelano

Example of broken workflow execution on my fork.

Import GPG Key step is expecting an input (from secrets) with the private key.

The problem could be solved by adding that secret on the fork but I think it would be better if tests do not have those types of external dependencies. In fact, other tests use a GPG private key included in the fixtures folder.

I think we can read that key in the workflow and pass it to the crazy-max/ghaction-import-gpg@v4 action. In fact, we do it for unit test here. Since this is an integration test we should not use that code. I called it integration tests because we test the integration of the action into the workflow, but they are also e2e tests, I mean we use the action as a black box.

On the other hand, the job integration-tests-with-commit-signature is actually not signing commits as you can see here. That's because the import-gpg step has the input git_commit_gpgsign: false, so we do not change global Git configuration to sign all commits. WE could do it on each git-queue action with the inputs git_commit_gpg_sign and git_commit_no_gpg_sign.

We do not like the git-queue to sign commits. That feature was implemented at the beginning but in the future, we would prefer not to sign commits and let the user sign all newly created commits later on. This way consumers do not need to trust the git-queue action.

For the time being, I'm going to keep that feature and change the workflow to sign commits, but using the action instead of the import GPG key step. Because it would not make any sense to test the other action unless we want to make sure git-queue does not change the signature.

Besides, we should make the workflow fail when the generated commits do not have the signature. We can start implementing that change. We do it for unit tests but I do not know how to do it in the workflow. We have to somehow parse the git show or git log output.

@da2ce7 do you think it makes sense to spend time fixing this bug? or we should delete the feature to sign commits with git-queue. In this case, we can keep the test only to be sure git-queue does not change the original signature.

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions