Looks good, thanks!
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Oct 27 2022
Build is green
This is a duplicate of the last update. I'm hoping that Arcanist
is now happy with my Git remote settings and will be able to push
the changes to the staging repo to be picked up by CI.
Build has FAILED
Use a Git SHA-1 for the payload.
Oct 26 2022
Build is green
In D8783#228307, @anlambert wrote:Better like this indeed, could you add a test with a sample credentials config file to check github_session object has loaded credentials ?
LGTM
LGTM
LGTM, added some nitpicks about typing as inline comments.
With latest diffs, the filtering seems to sort properly the files and tarballs for the guix manifest:
/me sighs
In D8775#228206, @vlorentz wrote:Dulwich calls it "raw_string", so I went with that
Dulwich calls it "raw_string", so I went with that
This is the POST request I received from Bitbucket when pushing commit to a sample repository.
Build is green
LGTM
Adapt according to last review
Regarding JSON payload sent by SourceForge, we cannot guess the visit type (git, svn, or hg) from it so we will have to query the project endpoint from SourceForge REST API to get it.
Build is green
In T4548#97884, @vlorentz wrote:In T4548#97818, @anlambert wrote:Based on the received HTTP POST request headers, we should be able to determine which type of forge sent us the request and then
extract repository URL and visit type from the JSON payload in order to create a Save Code Now request when new commits are pushed.We can do that and it certainly works, but once we start allowing a single endpoint for all forges, we cannot go back.
What about a separate path for each forge type, so we have more flexibility later on? eg. to route/"cache" requests from some forges differently directly in Varnish
Rebase (commit id mismatch locally and in the diff, don't recall what changed)
-> must be the commit message.
I am not a big fan either of adding more tarball detection heuristics but after quickly hacking on the code, it seems this is the only way to handle these edge case URLS (plus there is some cases when even analyzing HTTP headers cannot help to detect if the URL targets a tarball P1512). So let's land this and move on in deploying and testing that lister on staging.
In T4548#97818, @anlambert wrote:Based on the received HTTP POST request headers, we should be able to determine which type of forge sent us the request and then
extract repository URL and visit type from the JSON payload in order to create a Save Code Now request when new commits are pushed.