cli run for the bitbucket lister, status ok:
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Jan 28 2021
cli run for the github instance, status ok:
Build is green
Rebase
yuck
yuck
Build has FAILED
Status update, the main part of the scheduler journal client is done [1]. 98M origins
referenced in the cache table.
Build has FAILED
Build has FAILED
Adapt according to suggestions
- make it parametric on both case
- fix test
Build is green
Rebase
Jan 27 2021
Build has FAILED
Build has FAILED
(for the test and the soon to be adapted, yes, my thoughts exactly ;)
Use the right repository...
Thanks again!
gitlab instance deployed, status ok:
Legacy option should be removed soon so no tests needed here ;-)
Build is green
Adapt according to review
This would be cleaner to process the url in the lister constructor instead (same as in debian one).
This is a tryout to generate a global schema of the staging environment (P929):
Build is green
Adapt according to review
It seems to be ok :)
Build is green
Drop unneeded requests_mock (at some point i wanted to use it)
In D4955#124737, @ardumont wrote:@anlambert, thanks, jsyk, i'm working on fixing failing test in the chroot debian in the end goal to deploy the listers in staging.
@anlambert, thanks, jsyk, i'm working on fixing failing test in the chroot debian in the end goal to deploy the listers in staging.
few requests, please:
- add tests with this commit; every introduced function should have at least one test.
- add doctrings to your new functions,
- improve the commit message (see https://chris.beams.io/posts/git-commit/ ); with the current one, I have no idea what exactly is done in this commit, and more importantly, why this is needed for.
Let's consider it as done.
Thanks :)
Looks good !
Build is green
In D4954#124699, @ardumont wrote:Less code to modify and easier to read and understand the intended behavior from my point of view.
maybe so.
One pro I see for your implementation is if at some point the main loop (get_pages)
fails to fetch something (which we don't currently expect to see the assert added
here), we'll have more information available in the log instead of an AssertionError.
We'll indeed have an actual HttpError with the status code and everything in the
stacktrace.All in all, i think you are right ;)