Upload libXRPL flow #5028
Upload libXRPL flow #5028
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## develop #5028 +/- ##
=======================================
Coverage 74.8% 74.9%
=======================================
Files 768 768
Lines 63134 63134
Branches 8867 8846 -21
=======================================
+ Hits 47244 47269 +25
+ Misses 15890 15865 -25 see 4 files with indirect coverage changes |
godexsoft
force-pushed
the
feature/ci-publish-libxrpl1
branch
from
9fed9c9
to
f7c169d
Compare
.github/workflows/libxrpl.yml
Outdated
| paths: | ||
| - 'src/ripple/protocol/impl/BuildInfo.cpp' | ||
| - '.github/workflows/libxrpl.yml' | ||
| branches: [release] |
There was a problem hiding this comment.
Do we channel all of our releases through a single branch? I don't know. Even if we do, I'm not sure we can count on it always happening through a PR. I understand you want to publish a package before the commit is pushed to a protected branch or tagged. Can we get an expert on the release process to chime in? @seelabs?
Once we determine the right condition to check, we can think about how to deduplicate some of the steps here. Maybe we can move this workflow into a single conditional step at the end of the test workflow.
There was a problem hiding this comment.
Would be indeed useful to know if release is supposed to always be used for this purpose @seelabs 👍
When implementing this i deliberately sacrificed duplication for non-intrusiveness. I agree we can deduplicate quite a bit but i thought we would be better off creating a separate issue/PR for that. Let me know what you think @thejohnfreeman @seelabs .
There was a problem hiding this comment.
I've added a workflow in a branch that builds the Conan package locally and tests that an example downstream package can import it successfully. We could add a job to upload the recipe (and binary?) conditional on that test (and whatever conditions we decide determine a release).
There was a problem hiding this comment.
Not sure how useful it is to build an "example" package. Unless you have a package that uses everything libxrpl provides of course, in which case that's great.
I only really care that Clio (the only real/important consumer afaik) still works so I'd certainly prefer to leave the notification step that triggers Clio's CI. If you want to add an example package build in between - i have no problem with that.
I personally prefer to get simple things like CI out of the way and functional quicker and then improve if needed later.
There was a problem hiding this comment.
It is useful to test that, at least, libxrpl can be found and linked by a dependent package. It is possible to build a Conan package that doesn't actually export anything that can be linked.
There was a problem hiding this comment.
No, it's not required. But if i create a PAT from say my account it will probably use my account when creating PRs/issues from that workflow.
It's the easiest option.. but perhaps having some "XRPLD[bot]" account would be preferred?
There was a problem hiding this comment.
or would setting "resource owner" change the PR/issue author, do you know?
There was a problem hiding this comment.
I don't know. It can be tested though. Is there someone with organization permissions who we can delegate this to?
There was a problem hiding this comment.
I have evidence that it will still use the github-actions account to create the PR even if i use a PAT created for my account. I can create one and ask @ximinez to set it up in this repo.
There was a problem hiding this comment.
Not all releases are guaranteed to pass through release. Specifically, a hotfix (e.g. 2.2.1) can go directly to master without touching develop or release until it is backported. Also the paths and branches conditions are essentially ANDed together. No changes should ever get to release (or master for that matter) without the version number changing in BuildInfo.cpp, which would make that check redundant. Conversely, BuildInfo.cpp is almost never changed except to change the version number.
This contradicts what @seelabs said above. Take the example of 2.2.1, the reason is simple: The issue wasn't discovered in 2.2.0 until well after the first 2.3.0 beta had been merged to release. At that point, the only options were either roll back release (very bad), or let master and release diverge (not so bad).
Therefore, I suggest either:
- Remove
paths, and changebranchesto use bothreleaseandmaster. - Remove
branches, and leavepathsas-is.
Both risk adding extra builds, but drastically reduce the chances of missing a build, which seems like it would be worse.
.github/workflows/libxrpl.yml
Outdated
| paths: | ||
| - 'src/ripple/protocol/impl/BuildInfo.cpp' | ||
| - '.github/workflows/libxrpl.yml' | ||
| branches: [release] |
There was a problem hiding this comment.
Not all releases are guaranteed to pass through release. Specifically, a hotfix (e.g. 2.2.1) can go directly to master without touching develop or release until it is backported. Also the paths and branches conditions are essentially ANDed together. No changes should ever get to release (or master for that matter) without the version number changing in BuildInfo.cpp, which would make that check redundant. Conversely, BuildInfo.cpp is almost never changed except to change the version number.
This contradicts what @seelabs said above. Take the example of 2.2.1, the reason is simple: The issue wasn't discovered in 2.2.0 until well after the first 2.3.0 beta had been merged to release. At that point, the only options were either roll back release (very bad), or let master and release diverge (not so bad).
Therefore, I suggest either:
- Remove
paths, and changebranchesto use bothreleaseandmaster. - Remove
branches, and leavepathsas-is.
Both risk adding extra builds, but drastically reduce the chances of missing a build, which seems like it would be worse.
|
@ximinez should we wrap this one up? Anything in the PR needs changing? |
ximinez
added
the
Passed
Implements a CI workflow that detects when a new version of libxrpl is proposed, uploads it to artifactory under the `clio` channel and notifies Clio's CI to check this newly proposed version.
Implements a CI workflow that detects when a new version of libxrpl is proposed, uploads it to artifactory under the `clio` channel and notifies Clio's CI to check this newly proposed version.
High Level Overview of Change
Adding a workflow that automatically publishes
libxrplto a custom channel (clio/pr_NUMBER) Artifactory and triggers a workflow in Clio's CI usingrepository_dispatch.This flow will only run if the
BuildInfo.cppfile or the workflow itself was updated in a PR. Typically this means a new version is proposed.Publishing the library as soon as possible (i.e. not after merging it or tagging the version) gives us the ability to notify Clio's CI and trigger a full check against the new version of
libxrpl. In the future we could automate a notification back from Clio to report whether the checks were successful or not.This flow will start together with others (if conditions are met) but will not proceed with the upload until essential other checks are done and are either successful or skipped (not cancelled or failed). Currently the essential checks are all
testrunning onlinux. Mac and Windows are not on the list. Main reason for that is Mac being flaky and we don't want to fail this step (at least not often).Two secrets that need to be present in the repo (are already present):
And a new one that already was added in order to trigger a workflow on Clio's CI:
Here is the flow in Clio CI that does the rest: XRPLF/clio#1433
Currently Clio's side is broken because Conan's channel syntax contains a forward slash - a symbol that is not allowed for artifact names. This will be fixed on Clio side asap (XRPLF/clio#1583).
Context of Change
Recently there was an
rcoflibxrplthat did not allow consumers to link correctly. We should try and avoid this in the future.Type of Change
.gitignore, formatting, dropping support for older tooling)API Impact
None.