Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ENH: Add optional anaconda_nightly_upload_organization argument #47

Merged
merged 6 commits into from
Jan 24, 2024

Conversation

skoudoro
Copy link
Contributor

@skoudoro skoudoro commented Nov 29, 2023

This is a follow up and fixes #46

This PR goal is to allow other Scientific Python projects to use this github action.

Please, let me know what you think, and I will be happy to rename the variables if needed.

Thanks

Squash and merge commit

* Add optional `anaconda_nightly_upload_organization` and
  `anaconda_nightly_upload_labels` arguments to allow for packages
  to be uploaded to custom registires with the GitHub Action.
* Add docs to README providing an example of how to upload to an
  alternative registry.

NF: add anaconda_nightly_upload_token paremeter
DOC: Add associated documentation
Copy link
Member

@tupui tupui left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice 👍 thank you for the PR. LGTM but I am not coding actions often so another person with more experience there should also have a close look.

Copy link
Member

@matthewfeickert matthewfeickert left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm on a plane and so reviewing on the GitHub mobile app (which isn't the best, sorry) but can you elaborate on why labels are needed now? They shouldn't be AFAIK.

action.yml Outdated
Comment on lines 21 to 24
anaconda_nightly_upload_labels:
description: 'Labels assigned to the uploaded artifacts'
required: false
default: main
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is the label needed? This is a change in current behavior.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

By default, the label is main when you upload an artifact in anaconda

image

in our case (https://anaconda.org/dipy/dipy), the organization name is not explicit. I would like to avoid random people downloading nightly wheels and believing that is it a release. So, we tag them as dev instead of main (see the difference between the sreenshot above and below

image

one artifact can have one or multiple labels. I am fine for alternative solution to avoid confusion with users (since I can relabel all the old artifacts)

Documentation on anaconda label: https://docs.anaconda.com/free/anacondaorg/user-guide/work-with-labels/

@matthewfeickert
Copy link
Member

I'm on a plane and so reviewing on the GitHub mobile app (which isn't the best, sorry) but can you elaborate on why labels are needed now? They shouldn't be AFAIK.

Oh I guess this isn't a change in behavior given the current channel uploads

image

My bad. Can you document this optional variable though in your example?

Copy link
Member

@stefanv stefanv left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @skoudoro! It looks good to me; I left some feedback.

README.md Outdated Show resolved Hide resolved
README.md Outdated Show resolved Hide resolved
README.md Outdated
artifacts_path: dist
anaconda_nightly_upload_url: my-alternative-scientific-channel
anaconda_nightly_upload_token: ${{secrets.UPLOAD_TOKEN}}
anaconda_nightly_upload_labels: main
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
anaconda_nightly_upload_labels: main
anaconda_nightly_upload_labels: main

This is the default, so how about using a different label in the example?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

agree, I will update that

action.yml Outdated Show resolved Hide resolved
anaconda_nightly_upload_url:
description: 'URL to upload to scientific python org'
required: false
default: scientific-python-nightly-wheels
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
default: scientific-python-nightly-wheels
default: scientific-python-nightly-wheels

I don't know how the action works, but this is confusing since it isn't a URL.
If it can be anything other than a URL, that should either be documented or the field be renamed.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So the variable name is wrong! it should be anaconda_nightly_upload_organization

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

removing the default will break downstream packages using this action as soon as it is merged like scikit-image

scikit-image is using main. Maybe we can update this in a new PR and let some time to all downstream package to add/update this variable.

action.yml Show resolved Hide resolved
skoudoro and others added 2 commits November 29, 2023 15:34
Co-authored-by: Stefan van der Walt <sjvdwalt@gmail.com>
- rename anaconda_nightly_upload_url to anaconda_nightly_upload_organization
Copy link
Member

@stefanv stefanv left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me; I'll let @matthewfeickert do the final review and merge.

@matthewfeickert
Copy link
Member

Looks good to me; I'll let @matthewfeickert do the final review and merge.

Thanks all! 👍 I'm running in airports so if I have wifi on next flight I'll knock this final look over out and if not then I'll get to it tomorrow afternoon Europe time.

action.yml Outdated
anaconda_nightly_upload_labels:
description: 'Labels assigned to the uploaded artifacts'
required: false
default: [main]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@skoudoro Hey sorry to have one final question here (now that I've arrived), but can you point me to a reference on how you know that anaconda upload --label will accept a list of labels (as opposed to repeated calls of --label like how you would have to do with --channel with micromamba install? micromamba install --channel main --channel conda-forge numpy)?

The anaconda-client docs are not good, so it is possible I'm missing something. Have you tested this with any uploads to your registry yet?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can you point me to a reference on how you know that anaconda upload --label will accept a list of labels

As you can see below, I just used the help of the command line (anaconda upload --help.

image

There is also the following documentation : https://docs.anaconda.com/anaconda-repository/user-guide/tutorials/#using-labels-in-the-development-cycle

Have you tested this with any uploads to your registry yet?

Yes, I tried with some artifacts on our repository. I use the following command manually:
anaconda upload --force --user dipy --label dev --label main *1.6.0*.whl

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure how to handle the list with the docker. I am looking forward for your feedback

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

something is still wrong here, see the "Sequence was not expected" error in the CI: https://github.com/scientific-python/upload-nightly-action/actions/runs/7038337722/job/19199259041#step:9:1

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah @bsipocz's point is exactly my concern here. [main] is a sequence but @skoudoro the example you gave of

anaconda upload --force --user dipy --label dev --label main  *1.6.0*.whl

demonstrates the opposite of what you said. This is not a list, this is repeated calls of --label.

@skoudoro can you tell us more about how you're using labels now and why you want to have multiple labels?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes, I just updated the code. This is not a list, sorry for the confusion.

how you're using labels now and why you want to have multiple labels?

  • We use only the label dev for now
  • in our case (https://anaconda.org/dipy/dipy), the organization name is not explicit for nightly wheels. I would like to avoid random people downloading nightly wheels and believing that is it a release. So, we tag them as dev instead of main. it force user to be explicit and conscious of what they are trying to get. At the same time, it is not an issue for downstream packages.
  • we do not use multiple labels as the same time. the line above was just an example to show you how it can be done.

@matthewfeickert matthewfeickert changed the title NF: Add anaconda_nightly_upload_url ENH: Add optional anaconda_nightly_upload_organization argument Dec 1, 2023
@matthewfeickert matthewfeickert added documentation Improvements or additions to documentation enhancement New feature or request labels Dec 1, 2023
ANACONDA_ORG="scientific-python-nightly-wheels"
ANACONDA_ORG="${INPUT_ANACONDA_NIGHTLY_UPLOAD_ORGANIZATION}"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

would this break the current behaviour for the core libraries uploading to the default location?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, because I added the default location in this line: https://github.com/scientific-python/upload-nightly-action/pull/47/files#diff-1243c5424efaaa19bd8e813c5e6f6da46316e63761421b3e5f5c8ced9a36e6b6R20

However, I believe that:

  1. this parameter should be required instead of optional
  2. After merging, we should ask the core libraries to add and update this variable
  3. Then, when it is done, create a new PR here to remove this default location and let it empty.

Thank you for your review @bsipocz!

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@skoudoro While I'm not against the idea of being explicit about the target channel (I think that's a good idea in general to guard against default changes), I think the original intent for the GitHub Action was to make uploading as easy as possible for the core packages with the idea that they need to configure things as minimally as possible.

I think that this could probably be discussed more broadly outside of this PR though, so maybe you can open up an Issue from your comment to discuss what the target audience and scope of the action configuration should be?

action.yml Outdated
anaconda_nightly_upload_labels:
description: 'Labels assigned to the uploaded artifacts'
required: false
default: [main]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
default: [main]
default: main

This should be a string and not a sequence (c.f. #47 (comment))

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, agree.

I just read more about that and make sense

@skoudoro skoudoro force-pushed the new-paramater branch 2 times, most recently from bdca3eb to d6241ac Compare December 8, 2023 15:50
@matthewfeickert
Copy link
Member

(Sorry, been traveling for work to CERN and so haven't gotten back to reviewing this. Will try this weekend.)

@skoudoro
Copy link
Contributor Author

skoudoro commented Dec 8, 2023

No worries @matthewfeickert , take your times

- parse string in case of multiple labels
@skoudoro
Copy link
Contributor Author

skoudoro commented Dec 9, 2023

@bsipocz bsipocz mentioned this pull request Jan 1, 2024
@bsipocz
Copy link
Member

bsipocz commented Jan 4, 2024

ping @matthewfeickert, this would be good to have in sooner rather than later to help various downstream wheel production

@matthewfeickert
Copy link
Member

ping @matthewfeickert, this would be good to have in sooner rather than later to help various downstream wheel production

Yes, I'm aware but c.f. again #50 (comment) for why I've been preoccupied. I'll have a stable computer and get to this before end of week.

@bsipocz
Copy link
Member

bsipocz commented Jan 4, 2024

c.f. again #50 (comment) for why I've been preoccupied

Hah, fair enough, sorry for rushing you. I was also traveling, so I didn't really internalize all the comments from the past few weeks.

Copy link
Member

@matthewfeickert matthewfeickert left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@skoudoro Okay, sorry for a ridiculously long delay (😞) in this review from me (I've been without a working computer for multiple weeks). So I think this is overall good and the right approach, but the one important change is that this approach currenlty assume a space seperated list of labels, which is not a common assumption in the world of GitHub Actions where newline seperted or comma seperated lists are generally expected.

The suggested changes I've added in this review address that and change the logic to be able to handle newline or comma seperated lists of lables. I've tried to step through things to make the reasoning/motivation clear, but if you have any questions please feel free to ask (I promise I will be much more responsive now!).

action.yml Outdated Show resolved Hide resolved
cmd.sh Outdated Show resolved Hide resolved
cmd.sh Outdated Show resolved Hide resolved
@stefanv
Copy link
Member

stefanv commented Jan 23, 2024

In general, I would urge reviewers who want to see major refactors when a PR is close to its conclusion to push changes (when confident) or make PRs (of they want the contributor to review). This helps to keep things moving, and preserves contributor motivation.

@skoudoro
Copy link
Contributor Author

Sorry, I was traveling and then sick. I will get back to it by the end of the week (trying to catch up with everything). Apologize for that

@bsipocz
Copy link
Member

bsipocz commented Jan 23, 2024

In general, I would urge reviewers who want to see major refactors when a PR is close to its conclusion to push changes (when confident) or make PRs (of they want the contributor to review). This helps to keep things moving, and preserves contributor motivation.

I'm happy to do this (and am agree and tend to do this in places where I'm the primary maintainer and only have non-controversial or bikeshed comments), but feel that overtaking a PR where the contributor said they would come back to address another reviewer's comments can perceived as aggressive rather than helpful and I definitely would like to avoid that.

This PR was stuck on the reviewers' side for long enough that there is nothing to apologize for @skoudoro!

@matthewfeickert
Copy link
Member

In general, I would urge reviewers who want to see major refactors when a PR is close to its conclusion to push changes (when confident) or make PRs (of they want the contributor to review). This helps to keep things moving, and preserves contributor motivation.

@stefanv I think I share @bsipocz's feelings here, in that I am not a big fan of reviewrs pushing changes to code unless explictly asked to, which is why I always use GitHub's suggest changes tool so that if people agree with them they can incoperate as many as they wish into the PR with a simple button click and don't have to do any additional work themselves.

If pushing changes is preferred here I'm fine with that, and I will just accept my own proposed changes through the UI as a single commit. I'm happy to wait though to let @skoudoro have time to look at the proposed changes later this week.

@stefanv
Copy link
Member

stefanv commented Jan 23, 2024

Using the inline commenting system is indeed friendly in that regard, but when larger pieces of code needs to be re-written it becomes impractical and a PR to the contributor branch does the same.

We should, however, not be shy to help one another shoulder the load; I've never heard of a maintainer complain because other maintainers helped them too much. We all have long TODO lists that will never be completed in this lifetime!

@bsipocz
Copy link
Member

bsipocz commented Jan 23, 2024

We should, however, not be shy to help one another shoulder the load; I've never heard of a maintainer complain because other maintainers helped them too much.

fair enough, my experience with people being annoyed about PRs being taken over was PRs from generic (scientist or student) contributors rather than PRs from maintainers of other packages

@matthewfeickert
Copy link
Member

We should, however, not be shy to help one another shoulder the load; I've never heard of a maintainer complain because other maintainers helped them too much. We all have long TODO lists that will never be completed in this lifetime!

Okay, given this I'm going to accept my suggested changes as a single commit. @skoudoro to be explicit here, please take this as just a suggestion and feel free to revert or make any futher changes that you think would improve things. I'm happy to iterate with you further if needed! (though in full disclousure I have a job interview next week that is going to take me offline for most of it 😬 ).

Using space seperated lists is not standard across GitHub Actions, which in general assume that you're providing a newline seperatd or comma seperated list (c.f. https://github.com/docker/build-push-action?tab=readme-ov-file#inputs as an example).

So if we agree that we should be expecting newline seperated or comma seperated inputs then we can just treat all input the same by:

First, converting all input into a comma separated string
Then, create an array of the comma seperated labels
Finally, parse that array into a single string that represents all the label arguments to be included (you were already doing this part)
@stefanv
Copy link
Member

stefanv commented Jan 23, 2024

Thanks @matthewfeickert, and good luck with the interview!

@stefanv
Copy link
Member

stefanv commented Jan 23, 2024

Test failure 👀

ANACONDA_TOKEN is empty , exiting...

@matthewfeickert
Copy link
Member

matthewfeickert commented Jan 23, 2024

Test failure 👀

ANACONDA_TOKEN is empty , exiting...

That's expected. c.f. #32 (comment) for a not great summary, but basically there isn't a great solution at the moment to run the tests on PRs from froks that wouldn't potentially open up a security threat.

I'm not saying it is impossible to fix, but it would require a redesign of the CI.

(edit: I would be thrilled to learn that I'm wrong here, so please do take a look if you're inclined!)

@stefanv
Copy link
Member

stefanv commented Jan 23, 2024

That makes sense; I run into this all the time.

@bsipocz
Copy link
Member

bsipocz commented Jan 24, 2024

OK, so let's have this in now, thank you so much for all the efforts. If needed further adjustments can be done in follow-up PRs.

@bsipocz bsipocz merged commit f689fba into scientific-python:main Jan 24, 2024
1 of 2 checks passed
matthewfeickert added a commit that referenced this pull request Jan 24, 2024
* Use the correct shell variable "LABEL_ARGS" to pass the lable args to
  the `anaconda upload` command.
   - Amends PR #47
* Note that it is important that ${LABEL_ARGS} is NOT quoted during
  shell parameter expansion, else it will be treated as a file path to
  anaconda upload and not an argument.
   - e.g. This will trigger `File "--label main " does not exist`
     errors.
bsipocz pushed a commit that referenced this pull request Jan 24, 2024
* Use the correct shell variable "LABEL_ARGS" to pass the lable args to
  the `anaconda upload` command.
   - Amends PR #47
* Note that it is important that ${LABEL_ARGS} is NOT quoted during
  shell parameter expansion, else it will be treated as a file path to
  anaconda upload and not an argument.
   - e.g. This will trigger `File "--label main " does not exist`
     errors.
@matthewfeickert
Copy link
Member

matthewfeickert commented Jan 24, 2024

@skoudoro Can you verify that if you use

jobs:
  steps:
    ...
    - name: Upload wheel
      uses: scientific-python/upload-nightly-action@3eb3a42b50671237cace9be2d18a3e4b3845d3c4  # currently main
      with:
        artifacts_path: dist
        anaconda_nightly_upload_organization: my-alternative-organization
        anaconda_nightly_upload_token: ${{secrets.UPLOAD_TOKEN}}
        anaconda_nightly_upload_labels: dev

that things work for you to upload to your alternative registry? If so, I'll tag 3eb3a42 as v0.3.0.

@bsipocz
Copy link
Member

bsipocz commented Jan 24, 2024

cc @nabobalis if you want to try this out for openastronomy/sunpy

@skoudoro
Copy link
Contributor Author

Thank you all for pushing that forward.

@matthewfeickert, I just pushed the changes on dipy/dipy@66d08be. This is running

@skoudoro skoudoro deleted the new-paramater branch January 24, 2024 15:36
@nabobalis
Copy link

cc @nabobalis if you want to try this out for openastronomy/sunpy

Let me try.

@skoudoro
Copy link
Contributor Author

skoudoro commented Jan 24, 2024

@skoudoro Can you verify that if you use

jobs:
  steps:
    ...
    - name: Upload wheel
      uses: scientific-python/upload-nightly-action@3eb3a42b50671237cace9be2d18a3e4b3845d3c4  # currently main
      with:
        artifacts_path: dist
        anaconda_nightly_upload_organization: my-alternative-organization
        anaconda_nightly_upload_token: ${{secrets.UPLOAD_TOKEN}}
        anaconda_nightly_upload_labels: dev

that things work for you to upload to your alternative registry? If so, I'll tag 3eb3a42 as v0.3.0.

ok, it works ! Thanks @matthewfeickert ! Make sure to put the right commit number @nabobalis. The little code above was confusing (wrong commit number)

(edited by @matthewfeickert to avoid having invalid commit numbers provided by him floating about waiting to cause copy-paste errors)

@matthewfeickert
Copy link
Member

matthewfeickert commented Jan 24, 2024

The little code above was confusing (wrong commit number)

@skoudoro what's wrong with 3eb3a42 ?

(edit: Ah that I had typoed a f at the end! Fixed above)

@matthewfeickert
Copy link
Member

Okay, great as things seem to be working for dipy's uploads

image

I'll go ahead and make a new tag and release.

Thank you for the PR and for verifying this works, @skoudoro!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Improvements or additions to documentation enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Allow a new inputs parameter named anaconda_nightly_upload_url
6 participants