-
-
Notifications
You must be signed in to change notification settings - Fork 12
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
Automated monthly GMT 6.5.0 dev builds #100
base: devel
Are you sure you want to change the base?
Conversation
Hi! This is the friendly automated conda-forge-linting service. I just wanted to let you know that I linted all conda-recipes in your PR ( I do have some suggestions for making it better though... For recipe:
Documentation on acceptable licenses can be found here. |
Hi! This is the friendly automated conda-forge-linting service. I just wanted to let you know that I linted all conda-recipes in your PR ( |
f206dd1
to
9606d3e
Compare
@weiji14 You also need to update |
.github/workflows/bumpdevversion.yml
Outdated
- name: Check meta.yaml contents | ||
run: cat recipe/meta.yaml | ||
|
||
# TODO Commit changed recipe/meta.yaml file to Github |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@weiji14 I believe we can't add the workflow here.
To update a package, we are forced to
Please see the link. The main reason is
Branches are automatically published.
This means if you push a version update to a branch and then create a PR, conda packages will be published to anaconda.org before the PR is merged.
This isn't what we want.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah I did think of that. Do you think we can push to the GenericMappingTools org repo fork, or does it have to be a personal one?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think yes. The only limitation is that the org fork can't "allow edits from maintainers".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right, but it should be fine for you and Leo who are members of the GenericMappingTools org and this gmt-feedstock. I seem to recall we had an issue with updating the pygmt-feedstock from the GenericMappingTools org though? Edit: found it conda-forge/pygmt-feedstock#3.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I thought it's in this feedstock but couldn't find it.
It's here conda-forge/pygmt-feedstock#3. So the problem is that the bot can't update the @conda-forge-admin
bot can't update org repo.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It sounds too complicated. Perhaps the easiest way is still having a github action in a personal repo.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, it would be exact same workflow but in a different account. I would still be careful with letting the Actions script push the repo here without going through a PR first. Even the official conda-forge bot doesn't do that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure if it helps, but I've made a commit at 8a63a23 which would prevent the commit/branch-push job from running on 'conda-forge/gmt-feedstock' (see https://github.community/t/stop-github-actions-running-on-a-fork/17965/2). In theory, this means any other fork of 'gmt-feedstock' (with Github Actions enabled) would get a commit with the updated recipe/meta.yaml
file.
So at the very least, anyone can open a pull request from their personal fork (with the updated recipe/meta.yaml
file) to this upstream 'conda-forge/gmt-feedstock'. But I'm not sure if it's possible to automate this 😅 This problem has been raised at repo-sync/pull-request#18 though, and there was a proof of concept PR at repo-sync/pull-request#19. We could perhaps test this out somehow.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But I'm not sure if it's possible to automate this sweat_smile This problem has been raised at repo-sync/pull-request#18 though, and there was a proof of concept PR at repo-sync/pull-request#19. We could perhaps test this out somehow.
Ok, I've gone full circle with repo-sync/pull-request#19. The auto PR should work if either:
1. Using secrets.GITHUB_TOKEN
: works if PR happens on the same repo, i.e. conda-forge/gmt-feedstock/some-branch
to conda-forge/gmt-feedstock/devel
2. Using secrets.PERSONAL_ACCESS_TOKEN
: works across forks, i.e. username/gmt-feedstock/some-branch
to conda-forge/gmt-feedstock/devel
.
3. Experiment with adding /~https://github.com/conda-forge-linter as a member with 'write' permissions solely to the GenericMappingTools/gmt-feedstock
repo, to sidestep the "Allow edits from maintainer" issue.
Option 1 is definitely out of question, since we can't create forks on conda-forge/gmt-feedstock
itself. Option 2 means we rely on someone's personal repo, and it still requires that someone to setup a personal access token (so it's not as easy as it seems).
Option 3 (if it works) would be a bit more suistainable IMO, as potentially any member in the GenericMappingTools organization can edit the GenericMappingTools/gmt-feedstock
repo, crucial if one of us no longer actively contributes to the project. So should we try?
I'm not so sure about the security implications of this (giving a bot write permissions to GenericMappingTools/gmt-feedstock
), @leouieda probably has a better grasp on this. Yet another alternative (Option 4) is to make a Github App with the proper permissions, but this becomes an even bigger hassle to maintain (see /~https://github.com/peter-evans/create-pull-request/blob/master/docs/concepts-guidelines.md#authenticating-with-github-app-generated-tokens and /~https://github.com/tibdex/github-app-token).
Edit: The pangeo-dask-feedstock seems to have something very similar to what we want, implemented in conda-forge/pangeo-dask-feedstock#8. They use a pangeo-bot account though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, I've somewhat got it working (see example PR at #103) using a Personal Access Token (Option 2, make myself a bot). Currently the PR is from GenericMappingTools/gmt-feedstock
(rather than weiji14/gmt-feedstock) to conda-forge/gmt-feedstock
, so anyone on the GenericMappingTools organization (with permissions) should be able to modify the PR. Let me know if this is confusing.
Some notes:
- The bot seems to have linted the PR coming from
GenericMappingTools/gmt-feedstock
ok, I didn't set any special permissions at all. Maybe because I was the one who made the PR? - Maybe use the default Github Actions bot user, rather than have it look like I'm making the automatic PRs.
- Still need to tidy up the Github Actions workflow to be more readable
- Change 6.1.1... to 6.2.0...
@conda-forge-admin, please rerender |
Bump tibdex/github-app-token from 1.3.0 to 1.8.0, actions/checkout from 2.3.4 to 3.5.2, peter-evans/create-pull-request from 3.11.0 to 5.0.1.
The set-output command has been deprecated, see https://github.blog/changelog/2022-10-11-github-actions-deprecating-save-state-and-set-output-commands
Some sed substitution to fix the pin_compatible lines for fftw, gdal, zlib and curl. Also bumped yq from 4.9.6 to 4.34.1.
7a4ba5f
to
d9caca3
Compare
d9caca3
to
e783337
Compare
e783337
to
5f2e495
Compare
Bump actions/checkout from 3.5.2 to 4.1.6, peter-evans/create-pull-request from 5.0.1 to 6.0.5.
Hi! This is the friendly automated conda-forge-linting service. I just wanted to let you know that I linted all conda-recipes in your PR ( I do have some suggestions for making it better though... For recipe:
|
Hi! This is the friendly automated conda-forge-linting service. I just wanted to let you know that I linted all conda-recipes in your PR ( |
Hi! This is the friendly automated conda-forge-linting service. I just wanted to let you know that I linted all conda-recipes in your PR ( |
Need to run yq first, and then sed
8bb21a7
to
5dfb45d
Compare
5dfb45d
to
b842612
Compare
Starting a weekly GMT development build as mentioned in #95, so that users can install a more up to date version of GMT using:
Note that there's a few GMT 6.2.0 dev conda packages already at https://anaconda.org/conda-forge/gmt/files.
Workflow for the bot:
git ls-remote
)recipe/meta.yaml
file with new GMT package version and sha hash, should look like6.2.0.dev0+abcdefg
(use yq)3. Push the changedrecipe/meta.yaml
file to a branch called6.2.0.devX+something
, where X is some version number (use stefanz/git-auto-commit-action)4. Create a pull request for that branch (use vsoch/pull-request-action or repo-sync/pull-request)Notes:
dev
label https://anaconda.org/conda-forge/repo?label=devTODO:
and auto-merge👉 Manual instructions copied from #100 (comment)
Checklist
0
(if the version changed)conda-smithy
(Use the phrase@conda-forge-admin, please rerender
in a comment in this PR for automated rerendering)Fixes #95