-
Notifications
You must be signed in to change notification settings - Fork 51
Github specific workflow refactors and documentations #517
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
Conversation
Update github workflow configurations and platform files
|
This pull request sets up GitHub code scanning for this repository. Once the scans have completed and the checks have passed, the analysis results for this pull request branch will appear on this overview. Once you merge this pull request, the 'Security' tab will show more code scanning analysis results (for example, for the default branch). Depending on your configuration and choice of analysis tool, future pull requests will be annotated with code scanning analysis results. For more information about GitHub code scanning, check out the documentation. |
|
Coverage report for commit: c2570c8 Summary - Lines: 100.00% | Methods: 100.00% | Branches: 91.30%
🤖 comment via lucassabreu/comment-coverage-clover |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
…re should an artifact not exist yet
yevdyko
left a comment
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.
Thanks for the improvements — everything looks good! Regarding conventional commits, I’m personally not a big fan of them, especially for small projects with few contributors. That said, I don’t mind if you’d like to adopt this approach. The only thing I’d ask: could we avoid using emojis in commit messages? It feels a bit too much for my taste 🙂
Since you've updated all the workflow configurations here, I can extract the shared ones to the workflows repository after this PR is merged.
Could you remind me of the details about the p5 2.x.x migration? This topic slipped my mind
| - [ ] 📝 Documentation Issue | ||
| - [ ] 🤔 Question | ||
| - [ ] 🧹 Chore | ||
| - [ ] ❓Other |
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.
| - [ ] ❓Other | |
| - [ ] ❓ Other |
|
We need to upgrade p5 to v2.x.x and adapt implementation & the tests. I guess it makes sense to go into v5 before it's properly released since it's a breaking change. Or we release v5 as is and make v6 for the p5 upgrade but I don't think it makes sense to do 2 major upgrades in the space of a few weeks / months. What do you think? |
Proposed Changes
.githubdirectoryAdditional Notes (optional)
I would like to discuss the idea of enforcing conventional commits so that we can also auto-generate a changelog but what do you think of this @yevdyko? I think this would help to add more context for releases but it does mean the overhead of enforcing the commit style to achieve that end. That's the main trade-off but I think it could be worthwhile, I'm interested in your feedback on that.
Also, what is your plan for the
workflowsrepository and thep52.x.x migration we discussed? As an update from my side, theq5flows are almost finished and I just need to adapt the tests and change a couple of the types now before making the PR for that topic.