Support Ember 4.x / ember-auto-import 2.x #4179
Comments
AbhiPrasad
added
Package: ember
Right now, tests against the current release of ember are failing, because ember 4.0 brought changes our SDK isn't equipped to handle without breaking changes of its own. (See #4179.) Until we make those changes, we know that test scenario is going to fail. Meanwhile, GH is inconsistent in terms of what it considers success or failure in CI. GHA has a setting, `continue-on-error`, both for jobs[1] and for steps[2], which is essentially an xfail for a job within a workflow run (in other words, that job failing doesn't make the whole workflow run fail) and for a step within a job, respectively. This (in theory) allows processes which depend on the workflow or job succeeding to keep humming right along without the failure being silently swallowed. In our case, we have this set on the job running ember tests, so that if they fail, the entire workflow shouldn't. Indeed, if you look in the Actions tab, it shows up as green, in spite of the ember failures. But in terms of the little X or check next to commits/branches, and in terms of what it reports to craft, it shows up as red. This means that if anything else breaks, we won't know, since we'll already be expecting CI to be broken. It also prevents releases. This xfails the `ember-release` suite so that we can proceed with the rest of the repo as normal. We have the ticket linked above, and it's in our plan for the next major release (if it's not fixed before then), so we won't lose track of getting them fixed, even though we won't have the red X staring us in the face. [1] https://docs.github.com/en/actions/learn-github-actions/workflow-syntax-for-github-actions#jobsjob_idcontinue-on-error [2] https://docs.github.com/en/actions/learn-github-actions/workflow-syntax-for-github-actions#jobsjob_idstepscontinue-on-error
|
Eager to hear more about this issue. I'm trying to prepare our applications for Ember v4 and this is one of the things that's holding me back. |
|
Awesome, I'll be watching 👁️ |
Right now, tests against the current release of ember are failing, because ember 4.0 brought changes our SDK isn't equipped to handle without breaking changes of its own. (See #4179.) Until we make those changes, we know that test scenario is going to fail. Meanwhile, GH is inconsistent in terms of what it considers success or failure in CI. GHA has a setting, `continue-on-error`, both for jobs[1] and for steps[2], which is essentially an xfail for a job within a workflow run (in other words, that job failing doesn't make the whole workflow run fail) and for a step within a job, respectively. This (in theory) allows processes which depend on the workflow or job succeeding to keep humming right along without the failure being silently swallowed. In our case, we have this set on the job running ember tests, so that if they fail, the entire workflow shouldn't. Indeed, if you look in the Actions tab, it shows up as green, in spite of the ember failures. But in terms of the little X or check next to commits/branches, and in terms of what it reports to craft, it shows up as red. This means that if anything else breaks, we won't know, since we'll already be expecting CI to be broken. It also prevents releases. This xfails the `ember-release` suite so that we can proceed with the rest of the repo as normal. We have the ticket linked above, and it's in our plan for the next major release (if it's not fixed before then), so we won't lose track of getting them fixed, even though we won't have the red X staring us in the face. [1] https://docs.github.com/en/actions/learn-github-actions/workflow-syntax-for-github-actions#jobsjob_idcontinue-on-error [2] https://docs.github.com/en/actions/learn-github-actions/workflow-syntax-for-github-actions#jobsjob_idstepscontinue-on-error
|
Just a heads up - tried to update to
|
|
Looking at this in more detail and it may be related to my own config. I'll look into it and report back. |
|
Ok, this was my own config issue. Please disregard my nonsense. 🤦 |
|
It seems like this was resolved in #4253. @AbhiPrasad, do we still need this issue? |
|
Yeah we can close. |
@Emerson I'm also seeing this error, can you please share how you fixed it? (just a mention of the error to make it searchable) Edit: |
Hey folks.
We are currently investigating supporting Ember 4.x and ember-auto-import 2.x. This is a breaking change for our package, so we are exploring the best way to proceed with it.
As we make progress, we will update this issue with details. Thank you!
See some related issues:
The text was updated successfully, but these errors were encountered: