This repo host a collection of Github Actions and reusable workflows to build your Python software package and publish to an Anaconda repository. It is mostly inspired by existing projects such as build-and-upload-conda-packages or Publish Conda package to Anaconda.org and uses Setup Miniconda.

These actions have been primariliy developed for the needs of OpenAlea project. The associated development workflow is:

• create a branch for new development
• push on git (CI does nothing at this stage)
• when done, open a PR (CI will build on py_latest and test the package, but do not publish it)
• check CI results, ask for review, ammend PR (CI is re-run after each push)
• when CI and review are okay, merge PR (CI will build on py_latest and publish on dev channel)
• repeat open branch / PR / merge as much as needed
• when a new stable version of the package is ready for publication on openalea, go to 'actions' tab of your Github project, click on 'OpenAlea CI' and 'Run'. this will trigger a CI build on all supported os x py version.
• If CI check is okay, congrats, you can push a new tag (vx.x.x). CI will build, test and publish your package on rc (release candidate) channel.
• Publication on openalea main channel will be done by OpenAlea core developer team or during Release coding sprints.

If you belong to openalea organisation, please follow these installation instructions to activate CI on your repo.

If you want to test it in another context, just add and configure to your needs the following .github/workflows/openalea_ci.yml file in your repository:

name: OpenAlea CI

on:
... # triggering event of your choice

jobs:
  build:
    uses: openalea/action-build-publish-anaconda/.github/workflows/openalea_ci.yml@main
    secrets:
      anaconda_token: ${{ secrets.ANACONDA_TOKEN }}

By default OpenAlea CI listen to git-events happening on your repo and launch a set of actions that depends that event:

Note that for pure python packages, the publication is only triggered after build on ubuntu-latest.

During the development process, you might find yourself needing to test your package build without pushing to GitHub. However, using conda-build directly can mess with your local environment. To avoid this, we recommand to use the GitHub Local Actions VS-Code extension.

If you don't use VS-Code, you can still use nektos/act, a tool that allows you to run GitHub Actions locally, which is the core component of the extension mentioned above.

The most relevant case for testing openalea_ci workflow is probably when you're developing on your branch my_awesome_branch. However, you need to have an associated Pull Request to trigger the workflow (a "simple" push event on a development branch doesn't trigger any workflow, cf. https://github.com/openalea/action-build-publish-anaconda/blob/main/images/CI_workflow.png).

This can be specified in the VS-CODE "Github Local Actions" / "Workflows" section / "Run event" (thunder icon) - Pull Request event or directly running act pull_request.

• setup-ci : preliminary computation of inputs and environment variables to the builkd-publish-anaconda action as a function of the context (branch, tag, pull request, etc.).
• build-publish-anaconda : main action that actually builds the conda package and publishes it to an Anaconda repository.

• openalea_ci : main workflow that is meant to be used in your package. It combines the setup-ci and build-publish-anaconda actions.

• test_setup : for testing the setup-ci action in different simulated contexts.
• test_dummy : test the chaining of setup-ci and build-publish-anaconda actions on two dummy packages : one pure Python and one non pure Python.
• generate_docs : internal workflow that creates a PR to update the documentation of the actions and workflows in this repository.