Replies: 4 comments 6 replies
-
|
I agree that it is time to investigate GitHub Actions. Perhaps the Merge job would be a good place to start, since it is not as critical as the Pull Request job, and not as complex. The Merge job only runs the Unit tests, which are flaky enough for us to get experience handling GitHub Actions failures in angst, while not disrupting the existing PR process. Then once we are past the learning curve, switch over the Pull Request, Release, and other jobs. Would be nice if we could get an outlook for re-triggering individual jobs from GitHub, as that will cause some pain given the frequency of test flakes across the unit and integration test suites in the Pull Request job. |
Beta Was this translation helpful? Give feedback.
-
|
So, we could actually just enable pull-request jobs on GitHub Actions, and run them alongside AZP jobs for now but not mark them as required. This way we can see side-by-side how they compare without blocking development |
Beta Was this translation helpful? Give feedback.
-
|
I support this. I use github actions for CI in another Fabric fork and it was very straight forward to set it up, even for someone like me who has no patience to read instructions.
Yes this is unfortunate but it can totally be side stepped by having a build/check for each job. |
Beta Was this translation helpful? Give feedback.
-
|
Not totally side steppable (without doing some hacks), you can split the workflow and re-trigger UT and IT individually, but you can't re-trigger any of the IT matrix jobs individually if only one fails. |
Beta Was this translation helpful? Give feedback.
-
|
Right but you can make a check for each IT matrix job on its own |
Beta Was this translation helpful? Give feedback.
-
|
Thinking about moving to GitHub actions - got me thinking about the one other thing that you can do in github.. issues.. |
Beta Was this translation helpful? Give feedback.
-
|
Thats another topic we need to discuss in the coming months. Early next year our Jira server will be end-of-life (Atlassian is dropping support for on-prem), Ry has made a few comments that we need to revisit what we want to do at some point this year. In the next couple weeks GitHub will be releasing their overhauled "Issues" offering which is meant to provide a lot more functionality and features. Once that is released on the GitHub side, I think we can start evaluating whether we want to migrate to the new offering, Jira Cloud, or something else. So in a few weeks Ry and I will open another one of these discussions to talk about what we want to do there. |
Beta Was this translation helpful? Give feedback.
-
|
Fabric is pretty much the only project still on Jira, and even some of the Fabric projects are using Issues. Quite a few of the other projects have also migrated off of DockerHub and started using the integrated GitHub Container Registry now that they relaunched it as |
Beta Was this translation helpful? Give feedback.
-
|
If it can be done it is defnitely huge usage improvement towards Fabric ad-hoc contributors like us |
Beta Was this translation helpful? Give feedback.
-
|
Hope we can migrate to git hub action smoothly, and I hope we can decouple with CI tools during this migration. |
Beta Was this translation helpful? Give feedback.
-
Hello Fabric Community,
By now it should be common knowledge that Microsoft acquired GitHub in 2018. For the last two years this had left the hanging question of the future of Azure DevOps, and by extension Azure Pipelines, the CI tooling we use in Fabric. The Hyperledger community spent nearly a year trialing different CI platforms in 2019 before settling on Azure Pipelines. At the time GitHub Actions was a totally new offering from GitHub and in its infancy.
Unfortunately, despite engaging the larger Hyperledger community before finally choosing a CI platform to replace our legacy Jenkins instance, Azure Pipelines never gained traction outside of Fabric. Most of the projects eventually settled on other solutions, or GitHub Actions. Today most projects other than Fabric have landed on GitHub Actions, or are in the process of migrating to GitHub Actions.
While Azure has served us well over the last two years, it didn't come without it's caveats. Azure was never meant for open source and most of its features that were enabled for open source were afterthoughts. For example, only people who are part of our Azure DevOp's org can rerun failed CI builds. This meant we had to hack together a solution for automating the restart of failed builds. And in instances where this didn't work, to this day it means maintainers must manually re-trigger failed builds. To this day we still struggle with the GitHub service connections (a known issue), and frequently have to cycle permissions to make pipelines work, which requires us updating dozens of pipelines by hand. The few of us who manage these items are frustrated with both the process, and the lack of response from Azure on these bugs.
Beyond these complications, from an administrative point of view, it has been nothing short of a nightmare to provide access and permission to our maintainers on Azure. Since the Azure DevOp's permissions are disjoin from where we manage our maintainer lists (GitHub teams), adding and revoking access to Azure resources requires manual intervention, and frequently has issues due to user permission in their Azure account. This causes headaches for our Azure admins and the Hyperledger Admin team.
Now that Microsoft and GitHub are at an inflection point. It is well-known public knowledge that future of DevOps at Microsoft is GitHub, and no longer Azure DevOps. The Azure DevOps team is now part of GitHub and future feature development will land in GitHub and not Azure DevOps. In the coming months it is expected that Azure DevOps will be deprecated.
Migrating to GitHub Actions will give us more developer friendly features, for example, people will no longer need to jump out to Azure DevOp's to see their build, logs and artifacts, all of these items will reside alongside the code in the Checks tab of pull requests or on the Actions tab themselves. This should make it much friendlier for developers and for maintainers to review code. It will also allow for anyone to re-trigger builds without the need for custom code or maintainer intervention.
At this time, I would like to solicit questions, comments, or concerns about a migration to GitHub Actions. There are two notable differences I will point out between AZP and GHA:
Here is a PR I put together that runs both AZP and GHA side-by-side for now until we make a decision. It is also a chance to just see what it looks like for now: #2459
You can see the console on the
Checkstab of the PR: https://github.com/hyperledger/fabric/pull/2459/checks?check_run_id=2027432613Beta Was this translation helpful? Give feedback.
All reactions