-
-
Notifications
You must be signed in to change notification settings - Fork 19
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
Improved usage instructions in readme file #18
Conversation
b94a004
to
7dc8777
Compare
README.md
Outdated
```yaml | ||
name: "Continuous Integration" | ||
|
||
on: [push, pull_request] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I should probably explain why I used the following:
on:
pull_request:
push:
branches:
- '[0-9]+.[0-9]+.x'
- 'refs/pull/*'
tags:
What I found (through a LOT of trial and error), was the following:
- I started with just pull_request. When I did that, additional pushes to the PR branch would not trigger checks.
- When I added "push", without qualifications, I would get TWO runs of checks on opening a PR, one for the PR, and one for the branch. This led to unnecessary builds.
- If I added branches to the mix (as I did) to qualify which branch triggered a build... tags would not build.
Basically, I found on: [push, pull_request]
was building too much, which led me to qualify the values.
If you can point to repos where you have rolled out a workflow with the simplified entry, please link me to it so I can see the build history and make sure it's working the way I would want it to; until then, I'm a bit wary of this change.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've thought that - '[0-9]+.[0-9]+.x'
might be too much for projects which do not follow the branch strategy required by the laminas-automatic-releases
GHA.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could demonstrate two variants, then, maybe:
- The one we're using (and link to automatic-releases to detail the why aspect)
- A more general one (and detail issues such as double-runs, if they're still valid)
Improved usage instructions Fixed docker image name in local usage example Signed-off-by: Gennadiy Litvinyuk <gennadiy@gmail.com>
Changed events Signed-off-by: Gennadiy Litvinyuk <gennadiy@gmail.com>
…te CI runs Signed-off-by: Aleksei Khudiakov <aleksey@xerkus.pro>
Rebased to resolve conflicts. Added example with reusable workflow. Added mention of potential duplicate CI runs. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Minor suggestions, but changes look good, @Xerkus .
Co-authored-by: Matthew Weier O'Phinney <matthew@weierophinney.net> Signed-off-by: Aleksei Khudiakov <aleksey@xerkus.pro>
@gennadiylitvinyuk thank you |
Description
Improved usage instructions
Fixed docker image name in local usage example