Skip to content
This repository has been archived by the owner on Aug 2, 2022. It is now read-only.

GitHub Actions? #100

Open
lvillani opened this issue Dec 8, 2020 · 1 comment
Open

GitHub Actions? #100

lvillani opened this issue Dec 8, 2020 · 1 comment
Labels
question Further information is requested

Comments

@lvillani
Copy link
Member

lvillani commented Dec 8, 2020

Would it be possible to migrate from AppVeyor to GitHub Actions? This way we have a single CI provider across the entire project.

@lvillani lvillani added the question Further information is requested label Dec 8, 2020
@pgaskin
Copy link
Contributor

pgaskin commented Dec 8, 2020

That's an option I'm evaluating for the final part of #97.

Even though it would be the cleanest and easiest to use, Drone is out of the question since the cloud version doesn't support cron jobs (and I don't want to make a mess of triggering it using another cron job elsewhere).

The disadvantage of AppVeyor is how linear it is (it would make it more difficult to have failing steps while still running the rest). The same applies to Travis, which also has it's own disadvantages due to the new billing system.

This leaves GitHub Actions and a few others. I'm looking into and testing the following criteria:

  • Supports cron.
  • Optionally supports running without being attached to a specific commit.
  • Can run steps regardless of the entire pipeline's status.
  • Preferably is not blocked by download pages (we've had issues in the past, and that was one reason why AppVeyor was used).
  • Preferably supports multiple steps with their own status.
  • Preferably supports multiple groups of steps/individual pipelines.
  • Can preserve files between steps.
  • Supports secrets.
  • Preferably supports PTY features in the build log viewer.
  • Preferably supports Docker images.

Based on what I've looked at so far, GH Actions seems to be the most likely option.

Some things I'll be implementing in the new pipeline:

  • Saving a list of rules which failed and their errors, then passing that to a step which runs regardless of the status to update the successful rules.
  • Separating tests for jiup-go itself and the updates.
  • TBD.
  • If possible: having cron status separate from individual commits, or at under a different name from the initial one.
  • Future: only testing changed rules for PRs.
  • Future, if using GH actions: line annotations for failing rules.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
question Further information is requested
Development

No branches or pull requests

2 participants