Skip to content
This repository has been archived by the owner on Jul 15, 2023. It is now read-only.

Request: Build, Test and Release tslint-microsoft-contrib using Azure Pipelines #656

Closed
lupine86 opened this issue Nov 26, 2018 · 6 comments · Fixed by #838
Closed

Request: Build, Test and Release tslint-microsoft-contrib using Azure Pipelines #656

lupine86 opened this issue Nov 26, 2018 · 6 comments · Fixed by #838
Labels
Status: In Discussion Please continue discussing the proposed change before sending a pull request.
Milestone

Comments

@lupine86
Copy link

lupine86 commented Nov 26, 2018

This is a request to implement continuous integration builds that test tslint-microsoft-contrib using Azure Pipelines. The pipeline would be developed to run tests across various versions of node on Windows and Linux on every commit. A release pipeline could also be used for releasing/publishing to npm and NuGet and automate the versioning described in https://github.com/Microsoft/tslint-microsoft-contrib/wiki/Releases.

Note: This request is to only build and release using Azure Pipelines and IS NOT a suggestion to move the GitHub repo to Azure Repos.

Note that I have already reserved the account "tslint-microsoft-contrib" on Azure Repos and added some of the community members as admins. https://dev.azure.com/tslint-microsoft-contrib/tslint-microsoft-contrib

@JoshuaKGoldberg
Copy link

JoshuaKGoldberg commented Nov 26, 2018

Thanks for starting this @lupine86! A few notes on requirements for any CI build system:

  • It must have feature parity with what we have now:
    • Running on both Linux and Windows
    • Node versions 6, 8, 10, and 11
  • It shouldn't be significantly slower (and ideally should be a step up)
  • If we're going to switch, It should be able to release npm and NuGet packages ([enhancement] publish rules to nuget.org #346)
    • Ideally we should have nightlies set up

As nice as it is for Microsoft repositories to use Microsoft products, we should also note that TSLint core uses CircleCI. I think it's preferable for TSLint community rulesets such as this one to slowly move towards the same configuration as TSLint so that we can eventually have a ~single shared configuration (#258, #489, #575, palantir/tslint#4074).

(anecdotally, I just switched a larger project to CircleCI 2.0, and was very impressed with the speed and configuration - especially across multiple Docker containers)

Thoughts?

@JoshuaKGoldberg JoshuaKGoldberg added the Status: In Discussion Please continue discussing the proposed change before sending a pull request. label Dec 11, 2018
@JoshuaKGoldberg
Copy link

Ping @lupine86 - are you still interested in these changes? Travis has been a bit flaky lately so it'd be nice to switch to something else.

@lupine86
Copy link
Author

@JoshuaKGoldberg Hey Josh - yes! - I may not be able to get to them this week but it is only my list.

@willsmythe
Copy link

@JoshuaKGoldberg - I am a PM at Microsoft and work with @lupine86. We are happy to help on this. Give us a few days to dust things off, rebase, etc.

@apawast
Copy link
Contributor

apawast commented Feb 26, 2019

@JoshuaKGoldberg Hey Josh! I'm also a PM at Microsoft and work with @lupine86 and @willsmythe. I've updated the pipeline to run on both Windows and Linux and versions 6, 8, 10, and 11. Look out for an email from me today so I can understand and help you with your NuGet requirements better.

@JoshuaKGoldberg
Copy link

Awesome! Let's keep the majority of discussions here, but I've also emailed you asking for my personal email ([email protected]) to be added to dev.azure.com/tslint-microsoft-contrib. There's really nothing stopping us from onboarding Azure Pipelines alongside CircleCI, providing all maintainers who at Microsoft and/or active in maintaining (HamletDRC, IllusionMH, and myself) have access to that site.

As for replacing CircleCI, Azure Pipelines should be able to demonstrate:

  • not being flakier than CircleCI
  • not being slower than CircleCI

I'd like to see how it behaves over a month of repository usage, so we get at least several dozen builds to go off of. Seems like the best way to do that would be to merge #655! 😄

@apawast apawast mentioned this issue Mar 6, 2019
4 tasks
@JoshuaKGoldberg JoshuaKGoldberg added this to the None milestone Apr 15, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Status: In Discussion Please continue discussing the proposed change before sending a pull request.
Projects
None yet
4 participants