-
Notifications
You must be signed in to change notification settings - Fork 1
Add Zenodo integration #8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
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.
@alvarolopez
Question: is there a reason why we are not running qa for all branches?
anyOf {
 branch 'cicd'
 branch 'main'
 branch 'master'
 branch 'test'
 branch 'dev'
 branch 'release/*'
 }
Is it to save compute?
Because we need to think about how we are going to deal with the following usecases:
-
development environment: we are building tens of different tags (multiple Tensorflow versions, multiple Pytorch versions, etc) @vykozlov
-
demo app: we have branches
main
andreturn-files
which both need to be built. -
federated server: we have branches
main
andtokens
which both need to be built.
I get that building images for every branch creates lots of noise. In fact demo app currently has multiples branches that I do not want to build.
Proposal: maybe have a build/*
or deploy/*
naming pattern (similar to the release one) that will trigger the qa?
One could abuse the current release/*
pattern, but I think it might be cleaner to have another one.
What do you think?
2b5588b
to
3db8a90
Compare
This came from the old Jenkinsfile.
I think that we should define a pattern of what to build, for sure, lets discuss this offline and we can implement this in a different change. |
Enable GitHub and Zenodo integration for every repo
This change gets the Zenodo DOI for a given repository. As there is no way to programatically retrieve a Zenodo record for a GitHub repo, this change searches for the GitHub repo URL and gets the first result. Then, it creates a new branch, pushes it, and creates a pull request to the original repo.
No description provided.