[ELY-2056] Add a new GitHub workflow to trigger CI for pull requests. #1475
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
FYI the "PR Request CI" builds will be expected to fail as we also need the changes in #1474 |
fjuma
approved these changes
Dec 15, 2020
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
https://issues.redhat.com/browse/ELY-2056
At the moment this is just a minimal PR to get things going, to test and tweak the PR triggers we really need it set up against a repo that receives PRs to get used to how it behaves so we know what changes it needs.
I haven't added additional items yet for gathering any logs etc.. we can see if we need those but for now all failures I have seen were reproducible locally using a download of the Zulu JDK.
Also for now I have included macOS in the list, we have a concurrency limit of 5 - we may take that one out later but for now contributors may develop on macOS so worth considering.
We already have Elytron Web split out into a separate project and we plan so split Jakarta EE and MicroProfile modules into their own projects so at some point I would like to explore how change in Elytron can be tested against those projects and how PRs against those projects can also build against the latest Elytron so interactions can be tested. Initially maybe that would be against PRs but if not maybe could be based on push triggers or be scheduled to run nightly.