[question] PR workflows and [skip ci]

[ferdinandforgaard]

I'm working on a repo using semantic-release to automate the release process. Almost everything is working perfect, except one thing. When creating a PR from a branch with the head being a release commit, the commit will not trigger the build/test workflow we have set up, because of the [skip ci] keyword (see Utdanningsdirektoratet/Grep-komponenter#498 for an example).

Now I could work around this by using pull_request_target instead of pull_request and checkout the merge commit, but this might lead to repository compromise.

Another workaround would be to remove the [skip ci] keyword from the release commit, but then we need to add if checks in all our other workflows to stop them from running on every release commit.

Now I would not expect us to be alone with this issue and wonder how others might have dealt with this? What is the recommended approach to get build/test workflows to run on PR from branches with a release commit as head? Right now we are considering not running build/test workflow on PRs at all.

[travi]

it looks like you are only using the git plugin to commit the updated version in the package file. semantic-release does not need this to be managed in source control since it determines versions based on git tags/notes and sets the version before publishing to the registry. the simplest solution would be to simply stop using the git plugin. is there another reason why you are needing to commit the updated version to source control?

[ferdinandforgaard]

Hmm, I haven't thought about that. Should I not keep the version number up to date in the package files?

[ferdinandforgaard]

And no, as far as I know there is no other reason we commit the updated version to source control. But it seems like the common thing to do when releasing new versions?

[travi]

as we mention in our FAQ, updating the version number is only truly needed for the published package. some teams find it valuable to keep source control in sync with what is published, but tags can be referenced for that information instead.

our recommendation (and default behavior) is to leave the version alone in source control since updating it there does add a fair amount of complexity to the process. it can be helpful to set the version in source control to something obviously not the real version, like 0.0.0-semantically-released.

[ferdinandforgaard]

Aha! This seems to solve our problem and reduce complexity as well. Thanks a lot! Really appreciate the quick response

[arotka]

IMO it s logic to have the same version on tag and on package or pom files. that's keep easy to retreive version, why i should add another mapping beetween tag version and semantic release