search

MobilityData / gtfs-validator

Canonical GTFS Validator project for schedule (static) files.
https://gtfs-validator.mobilitydata.org/
Apache License 2.0
290 stars 101 forks source link

Release process improvements to be made #1719

Closed emmambd closed 7 months ago

emmambd commented 8 months ago

Release fixes:

davidgamez commented 8 months ago

Tasks:

jcpitre commented 7 months ago

For the notice migration generation, generating the PR at release time is problematic since the GH workflow needs a tag, but then when the generated PR is merged the commit will not be part of the release unless we move the tag.

I though I would do as suggested and make it a manual operation to be done before the release (and documented). That means having a workflow_dispatch trigger instead of a release trigger. That would not be difficult except it would require manually setting the version when starting the workflow. Is there an objection to that, or do you see an alternative? @cka-y @davidgamez @emmambd

davidgamez commented 7 months ago

I have no objections. If I'm reading correctly, this means the GH action at release time will publish the notice of migration currently in the repository as an asset. We just need to be aware of these steps to avoid publishing an out-of-date file.

jcpitre commented 7 months ago

I have no objections. If I'm reading correctly, this means the GH action at release time will publish the notice of migration currently in the repository as an asset. We just need to be aware of these steps to avoid publishing an out-of-date file.

It will not be a release asset. The process will be:

  1. Manually run the notice migration GH action (manually specifying the version) -> this adds to the NOTICE_MIGRATION.md file and creates the PR
  2. Merge the PR
  3. Release

This means the release will contain the updated NOTICE_MIGRATION.md file. The notice migration GH action will not be triggered by a release any more.

jcpitre commented 7 months ago

Delegated 2nd task:

to this issue: #1735