search

astropy / astropy-iers-data

IERS data maintained by @astrofrog and astropy.utils.iers maintainers
BSD 3-Clause "New" or "Revised" License
2 stars 6 forks source link

tag/publish workflows should not run for every push? #10

Closed pllim closed 1 year ago

pllim commented 1 year ago

https://github.com/astropy/astropy-iers-data/blob/main/.github/workflows/main.yml

Is this really meant to run every time someone push to main and PR branch? Sounds excessive.

astrofrog commented 1 year ago

Yes, the goal is to auto release as soon as the data files are updated - we can always adjust the frequency of the auto updates if this is too frequent but the idea is that PyPI should have recent versions of the files. Most PRs will just be the auto updates, so this should be ok, unless they are to change/fix something in which case we need to check the CI anyway.

pllim commented 1 year ago

unless they are to change/fix something in which case we need to check the CI anyway

Okay, but the workflow currently does not skip tag and publish even for PR. Will that mess things up?

pllim commented 1 year ago

And what if something is merged into main but has nothing to do with actual IERS update?

astrofrog commented 1 year ago

Tag only happens on main pushes (https://github.com/astropy/astropy-iers-data/blob/9748d8afb09b0d3c9a36bea8c88db2329c981a92/.github/workflows/main.yml#L33) - and yes we do want to do it even on regular PRs I think as those might be fixing something with the build for instance. There's really no harm in releasing on every main commit, as you can see from recent activity there really isn't much aside from the auto updates.

pllim commented 1 year ago

Well... I almost accidentally triggered a release by adding Zenodo badge to main. Luckily I added a [ci skip] last minute. But I might not remember every time!

pllim commented 1 year ago

I feel like this should just be a workflow_dispatch because you have to manually do a GitHub Release anyway to trigger Zenodo upload.

astrofrog commented 1 year ago

Will reply to this soon!

astrofrog commented 1 year ago

One of my goals with this package was to keep it as low maintenance as possible and to try and have things as automated as possible.

Now that things are running smoothly, I was actually planning to get rid of the automated update PRs and instead automatically commit to master if the CI passes - this is actually better than the current PRs for which the CI doesn't run by default. With this in place releases would be completely automated and I could have the workflow open an issue or PR if the workflow starts failing for any reason.

Changing to workflow dispatch goes the opposite direction of then having someone have to do multiple manual steps every week. I would prefer to automate the creation of GitHub releases if possible, and if not possible (eg if it doesn't trigger the Zenodo hook) then I don't think Zenodo releases are a sufficient motivation for switching a fully automated workflow to a weekly manual workflow so I would prefer to drop Zenodo.

pllim commented 1 year ago

Can we at least have the workflow not to publish unless it is that one IERS update bot push that matters? It is fine to want full automation but also need to prevent unnecessary releases. Thanks!

astrofrog commented 1 year ago

Yes that seems reasonable, I'll try and open a PR shortly to do all this.