I went through the Spack CI Github-Gitlab sync script to see what features might be good to include in Hubcast, and which would be better served as plugins.
The basic idea behind the script is to pull a list of all open PRs in the Spack repo, perform some filtering, and push the merge commits of those refs to the Spack Gitlab instance. Once the pipeline runs, the statuses are synced back to the Github checks for the PR.
There are some architectural differences with our approach, namely that the sync script is run as a cronjob and does not respond to push events like Hubcast.
I identified some important features implemented in the sync script that would be valuable to include in Hubcast or as an extension:
re prerequisite checks: is there potentially a more efficient way to implement this functionality without needing to make API calls to the status of existing checks? maybe as a dependent job in GitHub actions? not sure how feasible this is
cc: @kwryankrattiger, let me know if I'm missing anything
I went through the Spack CI Github-Gitlab sync script to see what features might be good to include in Hubcast, and which would be better served as plugins.
The basic idea behind the script is to pull a list of all open PRs in the Spack repo, perform some filtering, and push the merge commits of those refs to the Spack Gitlab instance. Once the pipeline runs, the statuses are synced back to the Github checks for the PR.
There are some architectural differences with our approach, namely that the sync script is run as a cronjob and does not respond to push events like Hubcast.
I identified some important features implemented in the sync script that would be valuable to include in Hubcast or as an extension:
all-prechecks). This could be a plugin.developpipeline runs; I would need to think more about how that should be set up. Not sure about tags, I don't think Hubcast implements that functionality.spackbot <noreply@spack.io>-- I'm thinking about writing up an account mapper for Hubcast that allows for a wildcard option: any user could push to the source forge, but the pipeline would run on behalf of a bot user on the destination forge, which would be done through impersonation tokens. However, this wouldn't change the author of the commit. This is currently implemented through merge commits, which Hubcast doesn't handle.re prerequisite checks: is there potentially a more efficient way to implement this functionality without needing to make API calls to the status of existing checks? maybe as a dependent job in GitHub actions? not sure how feasible this is
cc: @kwryankrattiger, let me know if I'm missing anything