Automatic packaging and CI test updates

[HGSilveri]

• Separates the requirements and dev_requirements
• Refactors the build workflow to install only the necessary packages for each job
• Creates a test workflow to run the unit tests across different OSs and python versions (triggered only on push events to master and develop)
• Adds a workflow to ensure the validity of the version numbers on master and develop
• Adds a workflow to build and publish and check stable releases to PyPI
• Documents the release process in detail

Closes #363 .

[AdrienFontaine-PASQAL]

Since I'm not familiar with Github Actions I had a quick question about the following piece of code (used for instance in .github/workflows/ci.yml):

on:
  pull_request:
  push:
    branches:
      - master
      - develop

Do we allow pushing commits directly to those branches (if so why/when)? Or are they "push protected" in a way? Maybe is this CI rule used for tagging the release commit?

The release.md only address tagging on master, so maybe the push rule is for detecting a PR that got merged?

[HGSilveri]

Since I'm not familiar with Github Actions I had a quick question about the following piece of code (used for instance in .github/workflows/ci.yml):

on:
  pull_request:
  push:
    branches:
      - master
      - develop

Do we allow pushing commits directly to those branches (if so why/when)? Or are they "push protected" in a way? Maybe is this CI rule used for tagging the release commit?

The release.md only address tagging on master, so maybe the push rule is for detecting a PR that got merged?

Hi @AdrienFontaine-PASQAL , thanks for taking the time to look into this!
Those branches are "push protected" except for collaborators with Admin rights. The "push" case will be triggered every time a PR is merged into one of these branches (which is admittedly redundant because the PR needs to pass all these tests to be merged) or on the rare occasions when an Admin does a direct push (what we want to catch).
There is no relation with tagging on this particular workflow.

[AdrienFontaine-PASQAL]

As far as my expertise go on Github Actions this sounds good to me.

[CdeTerra]

Great work, and thanks for the nice and clear documentation! I only have a few tiny comments.

[MatthieuMoreau0]

Question: Why do we not run test on push events ? Not super familiar with all the event types in github actions, so maybe these test are triggered through a merge_request event or something which would be redundant with the push event

[HGSilveri]

Just because I wrote a more complete test workflow to run only on push to the protected branches, so these would be redundant.

[MatthieuMoreau0]

nit: As per my other comment, having specific extras_require would have the extra benefit to avoid duplicating this grep magic several times

[HGSilveri]

True indeed

[anneclairelh]

These are mostly questions about your overall flow (therefore hopefully complementary to Adrien and Matthieu's review ) :)

[anneclairelh]

Does it mean that these tests would not run on feature branches before merging to develop?

[HGSilveri]

Exactly. I figured they are a bit excessive to be ran on every update to a PR. There are still tests in the ci.yml that should catch everything, these tests are run just to really ensure we didn't miss anything related to a specifc OS or python version.
On the rare case something fails, we can always follow up with a fix.