Closed tiagocoutinho closed 4 years ago
Maybe for CI it would make sense to add another meta.yaml that builds against the local filesystem instead. Let me know if you find it useful. I already have one skeleton that I prepared for this case
Yes, it would definitely be interesting.
and deployment to a conda forge channel would be awesome
But this can be done also on our internal gitlab CI that we use for debian packaging
and deployment to a conda forge channel would be awesome
putting it into conda-forge channel requires following an acceptance process with a probation period.
I have never done this so I don't know the details. My feeling is that it is too much trouble and you gain almost nothing.
I propose we place it in the "alba-controls" channel for now.
The only difference is that in the instructions we say:
conda install taurus -c alba-controls
instead of:
conda install taurus -c conda-forge
But this can be done also on our internal gitlab CI that we use for debian packaging
Agree, I think the gitlab CI is the right place for it. We probably need to:
anaconda upload -u <channel> <build file>
I propose we place it in the "alba-controls" channel
Of course, you are right . I was actually thinking on a "conda channel" , not "conda forge channel" but I wrote it wrongly. I agree alba-controls may be a good place for it
Regarding how to implement CI, if we use our internal gitlab-CI: any suggestion on which image to use for building the conda package? maybe one from https://hub.docker.com/u/continuumio ?
Also: if we implement CI/CD conda packaging in the packaging gitlab-CI, do you think it is worth merging this PR anyway?
Hi @tiagocoutinho , would it be possible for you to upload the meta.yaml that builds against the local filesystem ?
Also (or maybe, alternatively), it may make sense to automatically update the hardcoded version in the meta.yml file via bumpversion.
Sure, no problem. @rhomspuron found/improved a nice template which is I should use to upload here instead of the hack I did. It is quite elegant since most of it is agnostic to the package it is packaging (if the package fits the family of packages it was designed for: pure python, with semantic versioning, ...) which I think taurus fits well.
Hi, I just pushed deee234 as part of the preparation of the Jul20 release (#1127). It adds a conda/meta.yaml
based on the recipe from @rhomspuron.
Therefore I am closing this PR since it will be obsoleted by the next release.
Note: if I manage to do it, I'll try to include also an auto-deployment by travis
Yup!! I managed to automate the conda build and deployment (using github workflows), and also made it general for other projects to use the same configuration
This adds a conda recipe to be able to build taurus conda packages.
The recipe fetches a specific version taurus from pypi to build the conda package.
Maybe for CI it would make sense to add another meta.yaml that builds against the local filesystem instead. Let me know if you find it useful. I already have one skeleton that I prepared for this case