-
Notifications
You must be signed in to change notification settings - Fork 208
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
How to depend on successful tests? #137
Comments
Can't you protect your main branch by adding the required status checks? |
Thanks Luan for the response.
Yes, perhaps, but that will be rather tedious to accomplish across dozens of projects, especially if it needs to be done manually through the UI. Requiring a separate, manual step opens up opportunity for misconfiguration. Additionally, adding constraints on particular branches adds technical debt to those repositories. For example, this repository recently migrated from Ideally, I'd like a way that committing a change to the repository would enable the automerge functionality and gate them on the tests and work with a repository that's configured with the default settings. Is requiring status checks the recommended procedure for using automerge? If so, I'd expect that prerequisite to be documented in the Usage. |
Duplicate of #118 |
Would you consider accepting a pull request that updates the Usage documentation to add "enable protected branches and required checks" as a prerequisite step? |
I've updated the README a bit |
I've also learned that although it's possible to enable these checks through the API, it's not possible to know the names of the checks to know which to enable. They must be enabled one-by-one manually through the web UI :(. This constraint is enough of an impediment that I'll probably not be able to use this feature until there's better support for automation. |
Thanks for that. I still think it would be useful for the Usage section to have a prerequisite step, something like "first configure the repo with protected branches and required checks." For me, the nuances of setting up protected branches still feels hidden in the introductory section, and without a careful reading of that section, it's not clear that if applied to a repository configured with the default settings, the automerge action is unlikely to work as intended. It's a necessary step to first configure some branch protection with status checks (unless you want "tag with automerge" to have the same effect as clicking "merge"). |
I followed the usage docs and created a new action in my project, but when I did and tried to use automerge, it merged before the tests ran:
Presumably projects don't need an automerge action that's enacted immediately. What are the steps necessary to gate on tests passing? Given that's probably the most common usage scenario, could the usage be updated to include this important configuration detail (or point to an example that implements it that way)?
The text was updated successfully, but these errors were encountered: