repository_dispatch causes error

[voravor]

We hope this usage is potentially tenable, but realize it's somewhat bespoke.

We are triggering a PullPreview via a repository_dispatch from another repository+workflow, to run on the default branch tip, but this results in the following error:

/app/lib/pull_preview/sync_with_github.rb:230:in `sha': undefined method `[]' for nil:NilClass (NoMethodError)
	from /app/lib/pull_preview/sync_with_github.rb:159:in `update_github_status'
	from /app/lib/pull_preview/sync_with_github.rb:91:in `rescue in sync!'
	from /app/lib/pull_preview/sync_with_github.rb:52:in `sync!'
	from /app/lib/pull_preview/sync_with_github.rb:19:in `run'
	from /app/bin/pullpreview:78:in `<main>'
/app/lib/pull_preview/sync_with_github.rb:230:in `sha': undefined method `[]' for nil:NilClass (NoMethodError)
	from /app/lib/pull_preview/sync_with_github.rb:53:in `sync!'
	from /app/lib/pull_preview/sync_with_github.rb:19:in `run'
	from /app/bin/pullpreview:78:in `<main>

This was our way of testing a Wordpress plugin integration, using PullPreview to generate the WP environment. The triggering repo generates a custom build of the plugin and sends its url in the repository_dispatch payload.

We expected, since always_on: dev is set, that PullPreview would build using the current state of the dev branch. Any ideas about whether PullPreview can be configured this way?

[Cyril Rohr]

@voravor Can you try pullpreview/action@master? I just pushed a change that should help to handle that kind of triggers.

[voravor]

Thanks! Really appreciate the quick response. The trigger works, and the Lightsail instance is created as expected now.

[Cyril Rohr]

@voravor great to hear! Can I just ask if you already have a subscription for your company, or if you're using it for non-commercial purposes? Every little bit helps :) Thanks!

[voravor]

Just trying out right now! Love it, but honestly it would be great if there were more control over the resulting environment - e.g., a flag to instantiate a new Lightsail instance even if it is the same branch/commit.

Admittedly, this is tied to our specific use case of needing a unique environment every trigger which would stay up until we wanted to delete it.

[Cyril Rohr]

Just trying out right now! Love it, but honestly it would be great if there were more control over the resulting environment - e.g., a flag to instantiate a new Lightsail instance even if it is the same branch/commit.

Admittedly, this is tied to our specific use case of needing a unique environment every trigger which would stay up until we wanted to delete it.

@voravor Could be done pretty easily. But can you confirm that you would like the previous env to stay up (and thus have to remove them manually in the lightsail UI), or if you'd like the previous env to be automatically destroyed before starting the new one?

[voravor]

We were thinking: destroy acc'd a configurable option, e.g. when the PR is closed, or it is merged; or when the label is removed.

[Cyril Rohr]

@voravor are you still using pullpreview, and if so do you still require further control as to whether create a new environment from scratch every time? If so, please open a new issue so that I can track it better.

I will close this issue since the original problem has been fixed a while ago.