-
Notifications
You must be signed in to change notification settings - Fork 61
Conversation
I still need to do something with absolute paths in test C app. |
2dc475d
to
1ec2ecf
Compare
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.
Seems reasonable!
try { | ||
auto r = a->CampaignCheck().get(); | ||
if (!r.campaigns.empty()) { | ||
return new Campaign(r.campaigns[0]); |
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.
Is it fair to assume there will never be multiple campaigns? It would indeed be confusing if there were, but a comment to state the assumption might be worthwhile.
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.
It's not supported at the moment, so I think it's worth keeping it simple here. I'll add a comment.
src/libaktualizr-c/test/Makefile
Outdated
$(CC) -c -o $@ $< $(CFLAGS) | ||
|
||
api-test: $(OBJ) | ||
$(CC) -o $@ $^ $(CFLAGS) $(LIBS) |
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.
Why not use cmake? And either way, is there a way to integrate the test into the ctest framework?
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 started with having this test app completely separate, to be sure that linking works without any implicit cmake magic. But I guess I'll use cmake and add it to the ctest now.
@@ -17,9 +17,6 @@ add_aktualizr_test(NAME packagemanagerfake SOURCES packagemanagerfake_test.cc) | |||
# Debian backend | |||
if(BUILD_DEB) | |||
set_property(SOURCE packagemanagerfactory.cc packagemanagerfactory_test.cc PROPERTY COMPILE_DEFINITIONS BUILD_DEB) |
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 probably don't need to set this BUILD_DEB
definition here anymore, right? In fact, is BUILD_DEB
meaningful at all anymore? In CI it's built by default, and if it brings in no dependencies, there's hardly a reason not to just have it always on.
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.
That's a fair point, though we'd ship a code path that calls dpkg on yocto systems where it doesn't make sense. I don't know if the cost of keeping it (low, I think) warrants larger executables and potential bug surface.
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.
Probably true. Perhaps we should disable by default on CI and only enable it as necessary?
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.
Our approach on CI has been to enable all flags, so that everything can be tested at once. The things that are not covered tend to not compile after refactors.
Also, some unrelated useful tests use the Debian mode. For example memory_test. We'll probably migrate them when we can though.
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.
Fair enough. I have no objection.
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.
@patrickvacek, @lbonn Sorry, I'm a bit confused, what's your conclusion on that?
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 think just keep it as is?
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.
Cool, that's what I thought, just wanted to be sure.
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.
Yes, sorry for the distraction!
std::cerr << "Creating exception: " << e.what() << std::endl; | ||
return NULL; | ||
} | ||
return a; |
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.
Maybe, there will be a need/requirement to return some status/error code to am app using the C version of libaktualizr, otherwise the only way to find out what went wrong is by parsing stderr.
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.
@mike-sul Absolutely. But first, we'll need to make sure that exceptions thrown by libaktualizr are consistent and meaningful. I plan to work on that next.
Codecov Report
@@ Coverage Diff @@
## master #1263 +/- ##
==========================================
- Coverage 79.7% 79.04% -0.66%
==========================================
Files 173 175 +2
Lines 10301 10343 +42
==========================================
- Hits 8210 8176 -34
- Misses 2091 2167 +76
Continue to review full report at Codecov.
|
ed8b59f
to
b5a0d4f
Compare
Signed-off-by: Eugene Smirnov <[email protected]>
We shouldn't expect Config object to be alive after returning from Aktualizr constructor. As uptane_client_ uses Config in its destructor, we need to move the member declaration higher. Signed-off-by: Eugene Smirnov <[email protected]>
API of libdpkg is unstable and its usage is discouraged for purposes other than internal. It also prevents building libaktualizr as a shared library. As getInstalledPackages() functionality of debian package manager seems to be unused, we will avoid reimplementing it for now. Signed-off-by: Eugene Smirnov <[email protected]>
void Aktualizr_destroy(Aktualizr *a); | ||
|
||
Campaign *Aktualizr_campaign_check(Aktualizr *a); | ||
int Aktualizr_campaign_accept(Aktualizr *a, Campaign *c); |
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.
That's a bit annoying that we have to pass an Aktualizr instance to all of these. Would be handy if Campaign contained a pointer. But that might need changes in the C++ object, don't know if we want that.
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 see no problem in this, tbh. That's pretty much idiomatic C and is equivalent to Aktualizr->CampaignAccept(Campaign *c)
. If we do just a single arg here, I would expect our C++ API to also change to Campaign->Accept()
. I'm not sure if it makes it nicer, though.
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.
Ok I think you're right.
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.
On second thought, maybe it's not a bad thing to make those calls members of Campaign object. This way, we would prevent passing a campaign_id that belongs to another Aktualizr instance (a hypothetical situation, but still). WDYT, @lbonn @patrickvacek @mike-sul ?
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.
If it doesn't require changes to the C++ code, then that seems like the way to go. Even if it does, that seems to me to be a slightly better way to go.
err = Aktualizr_campaign_accept(a, c); | ||
Aktualizr_campaign_free(c); | ||
if (err) { | ||
return EXIT_FAILURE; |
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.
Will the aktualizr instance be properly tear-downed and freed in this case as well as in case of line #23 ? Or it's not important taking into account that the process is going to die anyway ?
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.
It won't, I forgot how to write proper C ;) But I'm rewriting this piece anyway
Would you mind guys merging this in the current state? It looks like doing the proper test for that will take me a bit longer. |
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.
Even if some comments are unresolved, this looks mostly fine and dropping libdpkg is already good.
So we can probably merge it and continue to work on it in other PRs.
@lbonn Cool, I'll merge it then and address the comments about the test app in the next PR. |
No description provided.