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

Automated monthly GMT 6.5.0 dev builds #100

Draft
wants to merge 82 commits into
base: devel
Choose a base branch
from

Conversation

weiji14
Copy link
Member

@weiji14 weiji14 commented Jul 28, 2020

Starting a weekly GMT development build as mentioned in #95, so that users can install a more up to date version of GMT using:

conda install -c conda-forge/label/dev gmt

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:

  1. On schedule, get latest GMT sha hash from Github (use git ls-remote)
  2. Update recipe/meta.yaml file with new GMT package version and sha hash, should look like 6.2.0.dev0+abcdefg (use yq)
    3. Push the changed recipe/meta.yaml file to a branch called 6.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)
  3. Just use peter-evans/create-pull-request which commits changed files to a branch and automatically creates the Pull Request!

Notes:

TODO:

👉 Manual instructions copied from #100 (comment)

Notes on how to be a bot and bump dev version locally. Assumes origin='weiji14', upstream='conda-forge' and GenericMappingTools='GenericMappingTools'. Need to ensure that GenericMappingTools/gmt-feedstock is in sync with conda-forge/gmt-feedstock first!!

git switch gmt-dev-builds  # Change to local gmt-dev-builds branch
git pull GenericMappingTools gmt-dev-builds  # Pull in changes from GenericMappingTools/gmt-dev-builds remote branch
git merge upstream/devel  # Merge in conda-forge/gmt-feedstock devel remote branch
git cherry-pick origin/gmt-dev-builds  # I.e. the 'Temp trigger auto PR commit' commit
git push -f origin

⚠️ Warning: Double check the git graph visually before doing the force push!

Checklist

  • Used a personal fork of the feedstock to propose changes
  • Bumped the build number (if the version is unchanged)
  • Reset the build number to 0 (if the version changed)
  • Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
  • Ensured the license file is being packaged.

Fixes #95

@conda-forge-linter
Copy link

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 (recipe) and found it was in an excellent condition.

I do have some suggestions for making it better though...

For recipe:

  • License is not an SPDX identifier (or a custom LicenseRef) nor an SPDX license expression.

Documentation on acceptable licenses can be found here.

@conda-forge-linter
Copy link

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 (recipe) and found it was in an excellent condition.

@weiji14 weiji14 marked this pull request as draft July 28, 2020 10:15
@weiji14 weiji14 changed the title WIP GMT 6.2.0 dev build WIP Automated weekly GMT 6.2.0 dev builds Jul 28, 2020
recipe/meta.yaml Outdated Show resolved Hide resolved
@weiji14 weiji14 force-pushed the gmt-dev-builds branch 2 times, most recently from f206dd1 to 9606d3e Compare July 28, 2020 23:56
@seisman
Copy link
Contributor

seisman commented Jul 29, 2020

@weiji14 You also need to update bld.bat and build.sh files in the devel branch. They're a little outdated.

- name: Check meta.yaml contents
run: cat recipe/meta.yaml

# TODO Commit changed recipe/meta.yaml file to Github
Copy link
Contributor

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

Used a personal fork of the feedstock to propose changes

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.

Copy link
Member Author

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?

Copy link
Contributor

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".

Copy link
Member Author

@weiji14 weiji14 Jul 29, 2020

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.

Copy link
Contributor

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.

Copy link
Contributor

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.

Copy link
Member

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.

Copy link
Member Author

@weiji14 weiji14 Jul 30, 2020

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.

Copy link
Member Author

@weiji14 weiji14 Aug 3, 2020

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?

Given conda-forge-linter write permissions to GenericMappingTools/gmt-feedstock

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.

Copy link
Member Author

@weiji14 weiji14 Sep 17, 2020

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...

@weiji14
Copy link
Member Author

weiji14 commented Jul 29, 2020

@conda-forge-admin, please rerender

weiji14 added 4 commits June 9, 2023 16:14
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.
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.
@conda-forge-webservices
Copy link

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 (recipe) and found it was in an excellent condition.

I do have some suggestions for making it better though...

For recipe:

  • This recipe is using a compiler, which now requires adding a build dependence on {{ stdlib("c") }} as well. For further details, please see META: {{ stdlib("c") }} migration conda-forge.github.io#2102.

  • In conda-forge.yml: $.compiler_stack = comp7.

    'Compiler Stack' is deprecated.
    Compiler stack environment variable. This is used to specify the compiler
    stack to use for builds. Deprecated.

    compiler_stack: comp7
    Schema
    {
      "anyOf": [
        {
          "type": "string"
        },
        {
          "type": "null"
        }
      ],
      "default": "comp7",
      "deprecated": true,
      "title": "Compiler Stack"
    }
  • In conda-forge.yml: $.max_py_ver = 37.

    'Max Py Ver' is deprecated.
    Maximum Python version. This is used to specify the maximum Python version
    to use for builds. Deprecated.

    max_py_ver: 37
    Schema
    {
      "anyOf": [
        {
          "type": "string"
        },
        {
          "type": "null"
        }
      ],
      "default": "37",
      "deprecated": true,
      "title": "Max Py Ver"
    }
  • In conda-forge.yml: $.max_r_ver = 35.

    'Max R Ver' is deprecated.
    Maximum R version. This is used to specify the maximum R version to use
    for builds. Deprecated.

    max_r_ver: 34
    Schema
    {
      "anyOf": [
        {
          "type": "string"
        },
        {
          "type": "null"
        }
      ],
      "default": "34",
      "deprecated": true,
      "title": "Max R Ver"
    }

@conda-forge-webservices
Copy link

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 (recipe) and found it was in an excellent condition.

@conda-forge-webservices
Copy link

conda-forge-webservices bot commented Jul 28, 2024

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 (recipe/meta.yaml) and found it was in an excellent condition.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants