-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unexpected LAGOON_GIT_SHA in PR environments #229
Comments
I have seen builds fail when the PR fails to merge cleanly into destination branch too. |
There's no other step in the process where it can happen? Github doesn't commit/save the result of a PR anywhere except inside Github. When we get a PR webhook, the payload only includes references to the
In order to prevent these issues we pull the head commit sha and the base commit sha out of the PR payload and we don't use branch names. When we merge during build, we're merging one commit into another, not one branch into another. |
What do you mean here by "valid PR environment"? Isn't the
The example payload you linked illustrates the problem with merging. If you take a look at the contents you'll see that "base": {
"label": "Codertocat:master",
"ref": "master",
"sha": "f95f852bd8fca8fcc58a9a2d6c842781e32a215e", If Even in the case that there has not been a commit to the So it seems as though the possible effects of the
IMO 2a is not desirable, since creating an ephemeral merge commit instead of using the Instead it seems that it would be faster, simpler and less surprising to do something like this and avoid merging altogether:
Where |
I guess there's some disconnect on what purpose a PR environment serves? Merging is a fundamental feature of a Lagoon PR environment:
If we never merge
But it's not different to how our competitors work. We're not a CI/CD system, our concept of a PR environment is not the same as theirs. PR environments are how Lagoon solves this problem for our users: As a user, I want an environment that has my |
Ah okay. Thanks for the explanation. Indeed I wasn't aware that this is the documented behaviour of Lagoon. 🙂
I thought it was so that you could push branches to the repo, and then only deploy PRs as environments. But I guess I should have read the documentation more thoroughly.
Several potential problems with doing the merge in the deploy are:
Maybe the Lagoon documentation should mention these pitfalls and also document that an alternative is to add a branch protection rule to your PRs? E.g. Github has: |
Workaround Add these lines to the
|
Describe the bug
When an environment is created from a PR, the
LAGOON_GIT_SHA
runtime environment variable is populated with a merge commit which only exists in the current build.There are a couple of levels of surprising behaviour here in my view.
Why is the PR branch merged during the build? If the merge target has had commits added to it since the PR branch diverged then there will be:
a) possibly a merge conflict which will fail the build; and
b) code from commits in the merge target added to the build which isn't in the PR branch.
Assuming that merging makes sense by ignoring the problems in 1., the
LAGOON_GIT_SHA
should be some value which is useful to the developer. A merge commit which only exists in the current build doesn't seem very useful, although it is technically accurate.To Reproduce
Steps to reproduce the behavior:
LAGOON_GIT_SHA
value in a PR environment.Expected behavior
I would expect Lagoon not to merge the PR during the build.
If that is required for compatibility or other reasons then the method for injecting the PR HEAD commit into a runtime variable should be documented. That would be something like this I think:
I had a look for this snippet in the Lagoon documentation but couldn't find it.
Screenshots
n/a
Additional context
git merge
during build occurs here.The text was updated successfully, but these errors were encountered: