On 2022-04-05, the default branch will be renamed from "master" to "main"

Really slick to do this after work hours, but some of us have offshore devops engineers who are all asleep. Now we can't run builds.

Really slick to do this after work hours, but some of us have offshore devops engineers who are all asleep. Now we can't run builds.

Thank you for the feedback @bc185168. We're trying to be as non-invasive as possible. If we did this during "Atlanta" time, it would be the middle of the night for Europe and Asia. There's never a convenient time 😦.

While I understand the reasons behind the naming changes I don't think breaking builds is the right call. Improving GitHub Actions to get it to properly follow the redirect or making copy of the @v0 branch called "master" would have avoided builds breaking all over the world and people scrambling to fix them. Breaking changes should only be made in the event of a critical security issue as they can have severe consequences on business.

What an unprofessional way of breaking everyone's integration.

Our entire product codebase and build pipeline is now broken.

Personally I was fine with this whole mumbles about main or master, even though it totally seemed nothing but a hypocrisy. However I think the way you pushed your idea is absurd and extremely careless.

Honestly you just broke all my pipelines and i have to change them all manually now, great!

We have been printing a warning message since December 29.

Yes because everyone read absolutely all the logs mostly of the things that works fine since the start right?

For next time:

• CHECK how much people pipeline you gonna break
• Inform them with EMAILS and more than one where you talk about BREAKING CHANGES
• Be CONSISTENT with the date where you are going to apply the breaking change. So far 2022-04-05 is not 2022-03-21
• DARE update your examples with main branch? all i see here are on: push: branches: - "master" pull_request: branches: - "master" on your own actions. --> https://github.com/google-github-actions/setup-gcloud/blob/master/.github/workflows/setup-gcloud-it.yml Don't you think this is slightly hypocrite (check ur own url line name)?

We have been printing a warning message [since December 29]

If a job will fail, it should fail on 2022-04-05, not 2022-03-21

It's hard to think of another social justice cause that had so much effort for such little impact.

And the worst thing in this is: Black Community, which is considered 'offended' in such cases, doesn't give a single damn how github (or whatever) calls the main/master/most_important/root branch. Yet another time white people decided for Blacks what they "want". Sad.

And the worst thing in this is: Black Community, which is considered 'offended' in such cases, doesn't give a single damn how github (or whatever) calls the main/master/most_important/root branch. Yet another time white people decided for Blacks what they "want". Sad.

I wasn't aware you were a spokesperson for the entire black community. I must have missed your anointment.

I wasn't aware you were a spokesperson for the entire black community. I must have missed your anointment.

I wasn't aware GitHub Google was, so it makes two of us.

guys this is not about master or main branches or github. This is about google been unprofessional in their way they handle their own changes. The branches of my crashed repositories where already using main in fact.

Black Community, which is considered 'offended' in such cases, doesn't give a single damn how github (or whatever) calls the main/master/most_important/root branch

1. I can understand if you have an opinion against Google renaming a branch by default, just don't claim to speak for everyone within a community. I know black people who don't care and many who do.

2. This is Google making a decision themselves, not claiming to speak for a specific community.

While I understand the reasons behind the naming changes I don't think breaking builds is the right call. Improving GitHub Actions to get it to properly follow the redirect or making copy of the @v0 branch called "master" would have avoided builds breaking all over the world and people scrambling to fix them. Breaking changes should only be made in the event of a critical security issue as they can have severe consequences on business. - @Alexandru-Dobre

@Alexandru-Dobre thank you for the suggestion. We have raised this issue with GitHub and the GitHub Actions team. They believe the current implementation is working as intended. Please keep in mind that we are not the GitHub Actions team and we have no control over how GitHub Actions behaves or resolves references.

Leaving a dangling master branch would have kept builds working, but that branch would have become stale and stagnant over time. Given the number of software supply chain and security issues, this did not feel like an appropriate path. Furthermore, creating a branch named "master" would break the redirect GitHub installs when a branch is renamed.

What an unprofessional way of breaking everyone's integration. - @savvaki

@savvaki - Thank you for the feedback. If you have alternative ideas, we're always open to exploring other options. Our team has been debating this change for many months. Our original attempt of renaming the branch in December broke with unintuitive and confusing error messages. The goal here is to provide a helpful and actionable error message for users.

Our entire product codebase and build pipeline is now broken. - @andoshin11

@andoshin11 - Sorry 😦. We've tried very hard to message this over the past 3 months, emitting warning messages. Please also note that it appears GitHub Actions also appears to be having issues, which is unrelated to our change. If you are seeing general build failures, it might be due to the GitHub issue.

Honestly you just broke all my pipelines and i have to change them all manually now, great! - @erwanriou

@erwanriou - Sorry about that. We've tried very hard to message this over the past 3 months, emitting warning messages. We did check how many pipelines we would break, and I personally submitted over 100 PRs to the top repositories. However, we can only check public repositories. We have no way of emailing maintainers. Please keep in mind that we are not the GitHub Actions team - we merely publish a GitHub Action for interacting with Google Cloud. If we had the information you suggested, we definitely would have used it.

As far as updating master -> main, we haven't made the change yet. The default branch is still named "master", but it throws this error when the GitHub Action is pinned to "master". On 2022-04-05, we are going to rename the branch from "master" to "main". At that point, we can no longer provide an informative and actionable error message, because the GitHub Action will fail at the control plane layer at GitHub (our code will not be invoked). This is what happened when we tried to rename the branch last year. To avoid non-actionable error messages, we're introducing this informative error, largely to echo your point about the warning message. The only mechanism we have to get users to pay attention is to throw errors.

If a job will fail, it should fail on 2022-04-05, not 2022-03-21 - @bc185168

@bc185168 - If we just renamed the branch on 2022-04-05, we would be replaying the December rename attempt.

guys this is not about master or main branches or github. This is about google been unprofessional in their way they handle their own changes. The branches of my crashed repositories where already using main in fact. - @erwanriou

@erwanriou - Could you please share more information? In our testing and in reviewing the code, you should only get this error if you're using google-github-actions/[email protected]. There is no main branch for this GitHub Action yet, and we advise against pinning to HEAD.

Please try to keep conversation civil. Comments not in line with Google's Code of Conduct are not tolerated.

Well, main is less "inclusive" and precise than master.

• master describes mastery, the flawless branch.
• main describes the ordinary branch for the main people. You won't hear of "main pieces", just "master pieces". Master comes from Meister, magister, not slave-owner as you do suggest. Master is an official craftsman job title. This is extremely offending to masters.

If we want to use the default, we just leave it out. Why recommend @v0 then?

I wonder if I need to change my MS diploma from Master of Science to Main of Science to be more inclusive?

Master comes from Meister, magister, not slave-owner as you do suggest

I'm curious where, in this issue, that Google suggested that they are changing the name of the branch because it means "slave-owner". I even "Cmd + F"'d and typed "slave" and the only match was your post.

I'm curious where, in this issue, that Google suggested that they are changing the name of the branch because it means "slave-owner". I even "Cmd + F"'d and typed "slave" and the only match was your post.

Cheap trick. We all know why this change was made, it's not our first day in the modern Internet.

I'm curious where, in this issue, that Google suggested that they are changing the name of the branch because it means "slave-owner". I even "Cmd + F"'d and typed "slave" and the only match was your post.

Cheap trick. We all know why this change was made, it's not our first day in the modern Internet.

I'll suggest to them that they don't suggest others' motives. Perhaps a better term would be:

Master comes from Meister, magister, not slave-owner as I believe to be the reason why this change was made

@erwanriou - Could you please share more information? In our testing and in reviewing the code, you should only get this error if you're using google-github-actions/[email protected] There is no main branch for this GitHub Action yet, and we advise against pinning to HEAD.

yes this is correct i use branch main and develop for my pipelines but at the time i did setup the github actions it was wrote to use google-github-actions/[email protected] that why i did so. I believe it was something about 1/2 years ago.
I am now switching everything to v0 but this issue for me leverage how sensitive this can be and my recommendation is that we setup ENV variable for it (in case it change again).

@erwanriou - Sorry about that. We've tried very hard to message this over the past 3 months, emitting warning messages. We did check how many pipelines we would break, and I personally submitted over 100 PRs to the top repositories. However, we can only check public repositories. We have no way of emailing maintainers.

Regarding that, this is quite an issue in fact. I would suggest try to inform Github about this specific concern and suggest a feature that would pass through them to be able to inform users of a specific Github actions. Because despite this was the first time happening to me, that mean it can happen and already happened in a lot of other cases for a lot of different people. And well since you are google you probably have more weight than me regarding this matter.

Thanks for the suggestions @erwanriou. We will discuss more usability improvements going forward with GitHub to make this experience less painful.

Since the redirect in GitHub Actions does not currently work then there should be no harm in keeping a branch called master temporarily. Yes, it will grow stale over time, but not more so than any tag and it should be possible to delete it once the redirect is fixed or another solution is found. In the worst case scenario, a security issue would force you to delete it at later date when much fewer companies would be affected by this.

As others have pointed out, few read those warnings in the logs and even those who do would have not expected the builds to be intentionally broken on March 21, 2 weeks before the announced date, as this was mentioned nowhere. Therefore, many companies were taken by surprise when the pipelines broke today. Not all of them have devops immediately available and even those who do will have to disrupt and delay tasks in order to handle emergency maintenance. People will work overtime, deadlines of projects for clients will be missed, costs will be incurred. Since this is not an honest mistake but an intentional disruption of service, affected companies would be well within their rights to present Google Cloud with the bill covering said emergency maintenance and any suffered disruption to their activities.

I must say I find it professionally unacceptable for a service provider to forcibly get their clients to "pay attention" by shutting down their pipelines and disrupting their business.

@sethvargo thanks for the heads up on this change! I am happy you were able to give me time to fix this up!

This process is unprofessional behavior. You're better than this

Since the redirect in GitHub Actions does not currently work then there should be no harm in keeping a branch called master temporarily. Yes, it will grow stale over time, but not more so than any tag and it should be possible to delete it once the redirect is fixed or another solution is found.

The easy thing to do would be to have both. Branches are cheap and writing a script to keep master in sync with the a new main branch is easy. So no remaining, full compatibility with old and new workflows.

All that was needed was to update all documentation to refer to main instead of master going forward.

Not breaking builds should be the prime objective of a GitHub Action, and keeping master around would accomplish that.

The main reason of investing into Google Cloud services was to ensure smooth and incident-free operation of our deployments and pipelines. The last thing we expected was for Google Cloud's Engineers to intentionally cause such an incident and to respond in such an unprofessional way to the complaints of their clients.

As others have pointed out, this was far from unavoidable and there was never any communication mentioning the date of 21 March. Furthermore, it is extremely unprofessional and condescending to attempt to shift the blame on your clients for not "paying attention".

No matter how you spin this, I refuse to believe it is acceptable for our pipelines to be intentionally disabled or that our only recourse in such an incredible situation is to fix them ourselves on our own time and money and move on.

I believe the right move would be to remove the intentional blocker currently breaking everyone's pipelines and to refrain from any further action that would break any workflow.

As this has been going on for two working days with no end in sight, the next logical step would be to file a complaint with Google Cloud in order to further escalate the issue. That seems to be the only way for us, clients, to get Google Cloud's engineers to "pay attention".

I like the environment variable name :)

Isn't this action deprecated? We were getting warnings to switch to google-github-actions/auth, so we did...

Hi @jamesmortensen - the setup-gcloud action isn't deprecated, but the "authentication" features are deprecated.

• auth - authenticate to google cloud for future steps
• setup-gcloud - install the gcloud CLI tool

I think along the way we've forgotten that backwards support for public services is imperative. Tooling like this must follow the browser update ethics which state that all previous features must be supported indefinitely, for better or worse.

This isn't some internal company tool, it's one that is integrated into many others with no proper way for you to contact them. Knowing that circumstance the master branch should have been locked at its current version and kept as archived after switching to a main branch, with warnings of depreciation left in the logs. Breaking every single integrator's CI should never have been the way to go, or even an option.