Closed ankostis closed 4 years ago
Reagarding security consideration for building our packages & images on CI infrastructure, this is typical practice by the industry. In principle, a resourceful actor can collude with Appveyor to introduce malevolent code into out EXE.
But in that case, i doubt we would be the only target, given that all conda-forge
packages are also built on the same CI provider.
Latest commit in dev
all checklists above implemented, mainly, the building of the EXE and the underlying recipes are now fully automated. The recipes uploaded automatically in https://anaconda.org/JRCSTU by the CI in https://ci.appveyor.com/project/ankostis/jrcstu-forge.
So the next release would need much less manual effort from Stefano (yet still the local PC is needed to update & test recipes).
A sample EXE is here: https://ci.appveyor.com/project/ankostis/jrcstu-forge/build/artifacts
Now that the release has been prepared, we can automate further the building of the EXE without pressure from a deadline.
By using the Appveyor CI cloud service for Windows VMs we automated the execution of conda's
constructor
tool, which is the last step for building the EXE.An important benefit, beyond the standardization and reduction of effort, is that the EXE gets produced in the cloud, and we do not have delays for uploading it from our PCs.
What is more time-consuming and error prone, is the packaging of PyPi packages into the respective conda-packages by following our own recipes of this project:
To build them, we may use TravisCI (another CI cloud service for Linux VMs) to build them, since they are all paltform agnostic,and linux is x5 faster in tasks like this. In additions we need the refactorings described below.
REFACTORINGS, Oct/Nov 2019
co2mpas
&co2wui
into newco2exe
projectconstructor.yaml
is not versioned).