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

Add GitHub Actions #709

Merged
merged 7 commits into from
Sep 16, 2022
Merged

Add GitHub Actions #709

merged 7 commits into from
Sep 16, 2022

Conversation

SeanKilleen
Copy link
Contributor

@SeanKilleen SeanKilleen commented Aug 3, 2022

Supports #695.

Starting with the out of the box template commit (which of course won't work) and then tweaking it from there.

@SeanKilleen
Copy link
Contributor Author

A note: you'll likely need to specifically enable GH Actions on the PR to allow it to run.

@tmenier
Copy link
Owner

tmenier commented Aug 5, 2022

Cool, this looks like it'll fit my existing processe well. Might need to change branch name at some point based on the outcome of #710 but that'll be easy enough to do later. No need for any versioning automation here, I think that could go in a separate release-oriented workflow, along with NuGet publishing etc.

Just a couple suggested modifications:

  1. How about renaming to ci.yml? (I've taken some inspiration from AutoMapper's workflows, they seem to run a very tight ship overall.)
  2. I'm thinking let's be bold and delete all AppVeyor-related bits right out of the gates, including the entire /build folder. I don't think any of it will be needed, but if I'm wrong, well, that's what version control is for. 😄

Thanks again!

@SeanKilleen
Copy link
Contributor Author

@tmenier

No need for any versioning automation here, I think that could go in a separate release-oriented workflow, along with NuGet publishing etc.

Sure -- happy to do that here or in a follow-up. Since you're looking at GitHub flow and a main branch + releases, you may want to either:

  • Tag releases manually with a version number and have the release workflow triggered on a tag being created with a certain specification
  • Or if you're feeling bold, you could do an auto-release via working something like Minver into your package. Every commit to main that comes between your tagged releases could then be published as a pre-release package.

But if you're happy to do that as a later step, I'm happy to leave it be for now 👍

How about renaming to ci.yml

Sure, I've got no hang-ups on names and that seems reasonable enough.

I'm thinking let's be bold and delete all AppVeyor-related bits right out of the gates, including the entire /build folder.

You've got it! Normally I do those in separate PRs because I like seeing the build pass before merging. 😆 However I'll do that right now.

dotnet is the default name; ci.yml is preferred by the author.
By suggestion of the maintainer.
@SeanKilleen SeanKilleen changed the title WIP: Add GitHub Actions Add GitHub Actions Aug 11, 2022
@SeanKilleen
Copy link
Contributor Author

Alright, changes made per suggestions -- happy to do more beyond this, just tag me with any input/needs you have!

@SeanKilleen
Copy link
Contributor Author

@tmenier I think you may need to allow GitHub Actions to run on this -- I can see it on my local, but not on this one. I think there may be a few failures to address and I'd like to see them here so I can review them with you if they happen.

@tmenier
Copy link
Owner

tmenier commented Sep 5, 2022

Sorry I've disappeared for a while, I have a bad habit of doing that when life gets busy. This is still very much on my radar and I hope to get to it merged in conjunction with some other work related to #710 very soon. Thanks again!

@tmenier tmenier merged commit bd1c114 into tmenier:dev Sep 16, 2022
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.

None yet

2 participants