Switching CI to GitHub actions

[hleb-rubanau]

This pull request reproduces previous Travis workflow on GithubActions with some tweaks & enhancements.

Key features:

• Workflow is named "CI & Release"
• Separate jobs: linter, test, smoketest, release
• Linter failure is tolerable
• Smoketest tries dockerhub login for better pulling but can proceed without it
• Release is only activated for selected branches (currently: master)
• If release happens outside of master e.g. during debug on ci/**, artifacts are pushed to testpypi instead of main repo (condition is configurable)

Examples:

• Development branch (not to be merged!) demonstrates release pipeline in action
• Same dev pipeline published package on testpypi
• Tags created by dev pipeline -- unfortunately, tag space pollution occured (from 2.1.9 to 2.1.15). Maybe for the future semantic-release should use conditional suffixes on non-master version tags (if such logic is supported)

After review and before merging:

• Delete tags created by dev pipeline starting from 2.1.9 to 2.1.15 (TODO: maybe use custom suffix for test runs of pipeline)
• Setup secrets:
  • POETRY_PYPI_TOKEN_PYPI (pypi user -- https://pypi.org/user/applandrobot/ )
  • DOCKERHUB_PASSWORD for applandinc user (this is optional but nice-to-have)
• (recommended) disable triggers for the repo on Travis-ci.com

[dividedmind]

Looks good, however I realized we seem to have lost access to the applandrobot pypi user — this might be a good excuse to set up OIDC connect publishing, see https://docs.pypi.org/trusted-publishers/

Could you take a look a that?

[github-actions]

🎉 This PR is included in version 2.1.9-dev.1 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀

[dividedmind]

@hleb-rubanau any progress? Do you need anything from me?

[hleb-rubanau]

@hleb-rubanau any progress? Do you need anything from me?

@dividedmind in fact, new version is kinda ready for a while -- I just was delayed with final test (which happens to also include workarounds for lost ownership on testpypi).

Hopefully will conduct it today and push changes.

[hleb-rubanau]

@dividedmind I've significantly reworked the whole flow

Key changes:

1. Releasing and publishing jobs are moved to their own release workflow, separate from linting and testing (but smoketest still is run before publishing to master)
2. Prerelease versions are fully supported (see .releaserc for details). Right now semantic-release is configured to trigger pre-release versions on ephemeral branch which I've used for testing. It can be changed to the branch of choice (develop/dev or similar)
3. Poetry now only builds artifacts, without publishing them. But exactly those artifacts are reused for all publishing steps.
4. Semantic-release creates github releases, and publishes artifacts attached to them
5. Publishing to pypi happens in a separate job, which runs after semantic-release and smoketest, is only activated on selected branches and uses trusted publishing mechanism
   5.1 For branches which name starts with ci, distribution names are altered without commiting and packages are published on test.pypi.org
6. Travis configuration file is deleted, and all toggles on Travis that trigger builds for the repo are set to off. However, I cannot delete the repo from travis acc.

Remark: I occasionally occupied project 'appmap' on the test.pypi.org and locked myself out of account. That was the reason to use altered distribution names in testpypi publishing flow. Documentation of testpypi promises regular wiping of accounts and assets so we can just wait for some time. If project and my abandoned acc stay there for long, I will try to reach out to platform administrators with explicit deletion request

[dividedmind]

Ok, LGTM!

I've added getappmap/appmap-python release.yml to trusted publishers. Anything else I need to do?

[hleb-rubanau]

I've added getappmap/appmap-python release.yml to trusted publishers. Anything else I need to do?

No, it should be sufficient. We can merge and check. Also I see someone needs to disable all Travis-related setttings in repo (right now github expects Travis CI check to be completed, which won't happen, because of toggles disabled on Travis side).

[dividedmind]

I've added getappmap/appmap-python release.yml to trusted publishers. Anything else I need to do?

No, it should be sufficient. We can merge and check. Also I see someone needs to disable all Travis-related setttings in repo (right now github expects Travis CI check to be completed, which won't happen, because of toggles disabled on Travis side).

Ugh, I wanted to change the branch protection to remove travis and add the gh, but it seems I'd have to add all the matrix jobs one by one. Gemini suggests adding a rollup job to simplify this:

# ... existing jobs ...

  # Add this new job at the end of your file
  check_enforce:
    name: Check (Rollup)
    runs-on: ubuntu-latest
    # Make sure this 'needs' matches the name of your matrix job
    needs: [test]
    if: always()
    steps:
      - name: Check build matrix status
        run: |
          # Check the status of the 'test' job (which includes all matrix variations)
          if [ "${{ needs.test.result }}" != "success" ]; then
            echo "One or more matrix jobs failed."
            exit 1
          fi
          echo "All matrix jobs passed."

Makes sense to me, more or less, what do you think? Can you add it if you think it's a good idea?

[dividedmind]

(It looked like there is a way to make the rule conditional on workflow, not check, but it seems to be only available to enterprise github for now, so do go ahead with the rollup check if you agree it makes sense.)