Skip to content

Automatically deploy cherry_picker (and/or blurb) to PyPI #222

Closed

Description

@Mariatta

I heard that this can be accomplished using TravisCI or CircleCI.

Activity

  1. Mariatta commented on Feb 13, 2018

    @Mariatta
    MemberAuthor

    TravisCI docs: https://docs.travis-ci.com/user/deployment/script/
    Might not work since cherry_picker now uses pyproject.toml instead of setup.py

    CircleCI example https://circleci.com/blog/continuously-deploying-python-packages-to-pypi-with-circleci/

  2. Mariatta commented on Feb 13, 2018

    @Mariatta
    MemberAuthor

    My own idea is to write a bot that does flit publish.

  3. webknjaz commented on Jun 10, 2018

    @webknjaz
    Member

    I can do it. If needed, I'll send a PR to travis-ci/dpl for the existing pypi provider (I wrote Pages provider, so I'm familiar with the tool), but it's likely that it won't be necessary.

    Another thing to consider would be the deployment flow trigger. Normally, I would do deploy for every tag pushed and even use that version-tag as a version of current distribution (see setuptools_scm).
    But in this repo there's two distributions (blurb and cherry-picker), which have different versions, so we need some hack to distinguish them.
    I suggest something like prefixing cherry-picker-vx.x.x or blurb-vy.y.y must be enough. If you don't wont to rely on git tags in dist you'll still have to edit and commit version in source and then tag it (as opposed to just tagging and pushing a commit).

    Regarding bot, I've got some ideas and having ongoing investigation of how GitHub Deployments APIs work along with GitHub Apps (login as a bot) + OAuth there. I don't have any public demo yet, but the plan is to make some UI with a button, which would trigger a deployment event and then the event listener part of app will react on such events and do whatever needed. I'm also considering another scenario where CIs will send such events. If I understand correctly, one may even add a condition into such trigger in API to wait for all CIs to complete, which is going to be very useful for aio-libs (where I originally intended to apply this), because in case of several CIs building OS-specific wheels asynchronously the wheels appear in PYPI during 8-hour interval, which seems to be very confusing to users. So this bot could be a nice "synchronization point" for such processes.

    But it all is just a theory for now. I'll start with what I know best: built-in deployment provider.

  4. added 2 commits that reference this issue on Jun 10, 2018
    076b715
    e6113fc
  5. webknjaz commented on Jun 10, 2018

    @webknjaz
    Member

    @Mariatta Please let me know if you prefer somewhat different flow. And perhaps we could move the discussion to #262, shall we?

  6. added 4 commits that reference this issue on Jun 11, 2018
    dc787d0
    1dfad2c
    076f934
    91b4aab
  7. added 2 commits that reference this issue on Jul 10, 2018
    f26b7cf
    354abdf
  8. added a commit that references this issue on Aug 4, 2018
    084b51e
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions