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

🌱 Downgrade to rollup v3 for multiarch builds #1742

Merged
merged 1 commit into from
Mar 5, 2024

Conversation

sjd78
Copy link
Member

@sjd78 sjd78 commented Mar 5, 2024

Following up on PRs #1664 and #1739, downgrade to rollup@^3.0. The v4 of rollup has "native" code that runs the build, and that code does not currently work with s390 builds [1]. Since konveyor is built for x86, arm, ppc, and s390, all of those need to work.

When the s390 builds can work with the wasm bits, we can upgrade to rollup@^4.0 again.

[1] - rollup/rollup#5354

Following up on PRs konveyor#1664 and konveyor#1739, downgrade to `rollup@^3.0`.
The v4 of rollup has "native" code that runs the build, and that code
does not currently work with s390 builds [1].  Since konveyor is
built for x86, arm, ppc, and s390, all of those need to work.

When the s390 builds can work with the wasm bits, we can upgrade
to `rollup@^4.0` again.

[1] - rollup/rollup#5354

Signed-off-by: Scott J Dickerson <sdickers@redhat.com>
@sjd78 sjd78 added the cherry-pick/release-0.3 This PR should be cherry-picked to release-0.3 branch. label Mar 5, 2024
@sjd78 sjd78 removed the cherry-pick/release-0.3 This PR should be cherry-picked to release-0.3 branch. label Mar 5, 2024
@sjd78 sjd78 merged commit ddcbccf into konveyor:main Mar 5, 2024
6 checks passed
sjd78 added a commit that referenced this pull request Mar 14, 2024
Following up on PRs #1664 and #1739, downgrade to `rollup@^3.0`. The v4
of rollup has "native" code that runs the build, and that code does not
currently work with s390 builds [1]. Since konveyor is built for x86,
arm, ppc, and s390, all of those need to work.

When the s390 builds can work with the wasm bits, we can upgrade to
`rollup@^4.0` again.

[1] - rollup/rollup#5354

Signed-off-by: Scott J Dickerson <sdickers@redhat.com>
sjd78 pushed a commit that referenced this pull request Mar 15, 2024
…1738)

## Summary
Refactor and enhance branding capabilities. Now branding is included
from a single directory that contains at least `strings.json`,
`manifest.json`, and `favicon.ico`. Any other assets may be placed in
the directory and will be copied to the bundled app.

Running the build as normal should show no difference.

Running the build with `BRANDING=./some-other-brand npm run start:dev`
will try to use a branding from the specified directory (that is relative to the
project's source root).

See `BRANDING.md` for more details.

Resolves: #1682

## Details
Branding changes:
  - Move Konveyor branding assets to a project top-level branding directory

  - Remove MTA branding assets

  - Remove profile/branding constants from `env` and client module

  - Embed branding strings and assets in the common module
    - `strings.json` is templated to allow the build to adjust asset URL path roots
       as necessary
    - `brandingAssetPath()`

  - server's index.html generation sources the template strings from the
    common module's branding strings

  - `HeaderApp` and `AppAboutModal` components support branding by using
    the `useBranding` hook

  - `BRANDING` as a relative path is computed from the project root

  - webpack build source branding assets directly from the common module

  - Unit tests, snapshots and jest configs updated as necessary

Jest changes:
  - Use `react-i18next` mock from `client/__mocks__` as a more robust mock
    borrowed from react-i18n repos

  - Move `setupTests.ts` into `client/src/app/test-config` to keep jest
    test config code all in the same directory

Related changes:
  - add new rollup plugins (copy, virtual)

## Downgrade to rollup v3 for multiarch builds (#1742)
As a followup on PRs #1664 and #1739, it became necessary to downgrade
back to `rollup@^3.0`. The v4 of rollup has "native" code that runs the
build, and that code does not currently work with s390 builds [1]. 

Since konveyor is built for x86, arm, ppc, and s390, all of those need to work.

When the s390 builds can work with the wasm bits, we can upgrade to
`rollup@^4.0` again.

[1] - rollup/rollup#5354

---------

Signed-off-by: Scott J Dickerson <sdickers@redhat.com>
Signed-off-by: Cherry Picker <noreply@github.com>
Co-authored-by: Ian Bolton <ibolton@redhat.com>
@sjd78 sjd78 deleted the revert_rollup3 branch March 16, 2024 00:20
sjd78 added a commit to sjd78/tackle2-ui that referenced this pull request May 10, 2024
If the workflow is run from a PR, and the PR includes
a change to the `Dockerfile`, then run image builds
for all of our target platforms.

The images are built but not pushed to any repository.

We want to be reasonably sure that any `Dockerfile` change
will not cause the image-build-and-push on PR merge workflow
to break.  Doing the image build here should show up most
problems much earlier.  For example, a npm version update
in the build container could break github action `nofiles`
or network access capabilities for the npm install.

In future, it may be reasonable to extend this check
to happen when other core build related changes are
made (package-lock.json, package.json).

See konveyor#1742, konveyor#1746, and konveyor#1781 for some other examples of
when this check could have caught issues before a PR
merge.

Supports: konveyor#1883

Signed-off-by: Scott J Dickerson <sdickers@redhat.com>
sjd78 added a commit to sjd78/tackle2-ui that referenced this pull request May 10, 2024
If the workflow is run from a PR, and the PR includes
a change to the `Dockerfile` or `package-lock.json`, then
run image builds for all of our target platforms.

The images are built but not pushed to any repository.

We want to be reasonably sure that any major build file changes
will not cause the image-build-and-push on PR merge workflow
to break.  Doing the image build here should show up most
problems much earlier.  For example, a npm version update
in the build container could break github action `nofiles`
or network access capabilities for the npm install.

See konveyor#1742, konveyor#1746, and konveyor#1781 for some other examples of
when this check could have caught issues before a PR
merge.

Supports: konveyor#1883

Signed-off-by: Scott J Dickerson <sdickers@redhat.com>
sjd78 added a commit to sjd78/tackle2-ui that referenced this pull request May 10, 2024
If the workflow is run from a PR, and the PR includes
a change to the `Dockerfile` or `package-lock.json`, then
run image builds for all of our target platforms.

The images are built but not pushed to any repository.

We want to be reasonably sure that any major build file changes
will not cause the image-build-and-push on PR merge workflow
to break.  Doing the image build here should show up most
problems much earlier.  For example, a npm version update
in the build container could break github action `nofiles`
or network access capabilities for the npm install.

See konveyor#1742, konveyor#1746, and konveyor#1781 for some other examples of
when this check could have caught issues before a PR
merge.

Supports: konveyor#1883

Signed-off-by: Scott J Dickerson <sdickers@redhat.com>
sjd78 added a commit to sjd78/tackle2-ui that referenced this pull request May 10, 2024
If the workflow is run from a PR, and the PR includes
a change to the `Dockerfile` or `package-lock.json`, then
run image builds for all of our target platforms.

The images are built but not pushed to any repository.

We want to be reasonably sure that any major build file changes
will not cause the image-build-and-push on PR merge workflow
to break.  Doing the image build here should show up most
problems much earlier.  For example, a npm version update
in the build container could break github action `nofiles`
or network access capabilities for the npm install.

See konveyor#1742, konveyor#1746, and konveyor#1781 for some other examples of
when this check could have caught issues before a PR
merge.

Supports: konveyor#1883

Signed-off-by: Scott J Dickerson <sdickers@redhat.com>
sjd78 added a commit to sjd78/tackle2-ui that referenced this pull request May 10, 2024
If the workflow is run from a PR, and the PR includes
a change to the `Dockerfile` or `package-lock.json`, then
run image builds for all of our target platforms.

The images are built but not pushed to any repository.

We want to be reasonably sure that any major build file changes
will not cause the image-build-and-push on PR merge workflow
to break.  Doing the image build here should show up most
problems much earlier.  For example, a npm version update
in the build container could break github action `nofiles`
or network access capabilities for the npm install.

See konveyor#1742, konveyor#1746, and konveyor#1781 for some other examples of
when this check could have caught issues before a PR
merge.

Supports: konveyor#1883

Signed-off-by: Scott J Dickerson <sdickers@redhat.com>
sjd78 added a commit to sjd78/tackle2-ui that referenced this pull request May 10, 2024
If the workflow is run from a PR, and the PR includes
a change to the `Dockerfile` or `package-lock.json`, then
run image builds for all of our target platforms.

The images are built but not pushed to any repository.

We want to be reasonably sure that any major build file changes
will not cause the image-build-and-push on PR merge workflow
to break.  Doing the image build here should show up most
problems much earlier.  For example, a npm version update
in the build container could break github action `nofiles`
or network access capabilities for the npm install.

See konveyor#1742, konveyor#1746, and konveyor#1781 for some other examples of
when this check could have caught issues before a PR
merge.

Supports: konveyor#1883

Signed-off-by: Scott J Dickerson <sdickers@redhat.com>
sjd78 added a commit to sjd78/tackle2-ui that referenced this pull request May 10, 2024
If the workflow is run from a PR, and the PR includes
a change to the `Dockerfile` or `package-lock.json`, then
run image builds for all of our target platforms.

The images are built but not pushed to any repository.

We want to be reasonably sure that any major build file changes
will not cause the image-build-and-push on PR merge workflow
to break.  Doing the image build here should show up most
problems much earlier.  For example, a npm version update
in the build container could break github action `nofiles`
or network access capabilities for the npm install.

See konveyor#1742, konveyor#1746, and konveyor#1781 for some other examples of
when this check could have caught issues before a PR
merge.

Supports: konveyor#1883

Signed-off-by: Scott J Dickerson <sdickers@redhat.com>
sjd78 added a commit to sjd78/tackle2-ui that referenced this pull request May 10, 2024
If the workflow is run from a PR, and the PR includes
a change to the `Dockerfile` or `package-lock.json`, then
run image builds for all of our target platforms.

The images are built but not pushed to any repository.

We want to be reasonably sure that any major build file changes
will not cause the image-build-and-push on PR merge workflow
to break.  Doing the image build here should show up most
problems much earlier.  For example, a npm version update
in the build container could break github action `nofiles`
or network access capabilities for the npm install.

See konveyor#1742, konveyor#1746, and konveyor#1781 for some other examples of
when this check could have caught issues before a PR
merge.

Supports: konveyor#1883

Signed-off-by: Scott J Dickerson <sdickers@redhat.com>
sjd78 added a commit to sjd78/tackle2-ui that referenced this pull request May 10, 2024
If the workflow is run from a PR, and the PR includes
a change to the `Dockerfile` or `package-lock.json`, then
run image builds for all of our target platforms.

The images are built but not pushed to any repository.

We want to be reasonably sure that any major build file changes
will not cause the image-build-and-push on PR merge workflow
to break.  Doing the image build here should show up most
problems much earlier.  For example, a npm version update
in the build container could break github action `nofiles`
or network access capabilities for the npm install.

See konveyor#1742, konveyor#1746, and konveyor#1781 for some other examples of
when this check could have caught issues before a PR
merge.

Supports: konveyor#1883

Signed-off-by: Scott J Dickerson <sdickers@redhat.com>
sjd78 added a commit to sjd78/tackle2-ui that referenced this pull request May 10, 2024
If the workflow is run from a PR, and the PR includes
a change to the `Dockerfile` or `package-lock.json`, then
run image builds for all of our target platforms.

The images are built but not pushed to any repository.

We want to be reasonably sure that any major build file changes
will not cause the image-build-and-push on PR merge workflow
to break.  Doing the image build here should show up most
problems much earlier.  For example, a npm version update
in the build container could break github action `nofiles`
or network access capabilities for the npm install.

See konveyor#1742, konveyor#1746, and konveyor#1781 for some other examples of
when this check could have caught issues before a PR
merge.

Supports: konveyor#1883

Signed-off-by: Scott J Dickerson <sdickers@redhat.com>
sjd78 added a commit to sjd78/tackle2-ui that referenced this pull request May 10, 2024
If the workflow is run from a PR, and the PR includes
a change to the `Dockerfile` or `package-lock.json`, then
run image builds for all of our target platforms.

The images are built but not pushed to any repository.

We want to be reasonably sure that any major build file changes
will not cause the image-build-and-push on PR merge workflow
to break.  Doing the image build here should show up most
problems much earlier.  For example, a npm version update
in the build container could break github action `nofiles`
or network access capabilities for the npm install.

See konveyor#1742, konveyor#1746, and konveyor#1781 for some other examples of
when this check could have caught issues before a PR
merge.

Supports: konveyor#1883

Signed-off-by: Scott J Dickerson <sdickers@redhat.com>
sjd78 added a commit to sjd78/tackle2-ui that referenced this pull request May 13, 2024
If the workflow is run from a PR, and the PR includes
a change to the `Dockerfile` or `package-lock.json`, then
run image builds for all of our target platforms.

The images are built but not pushed to any repository.

We want to be reasonably sure that any major build file changes
will not cause the image-build-and-push on PR merge workflow
to break.  Doing the image build here should show up most
problems much earlier.  For example, a npm version update
in the build container could break github action `nofiles`
or network access capabilities for the npm install.

See konveyor#1742, konveyor#1746, and konveyor#1781 for some other examples of
when this check could have caught issues before a PR
merge.

Supports: konveyor#1883

Signed-off-by: Scott J Dickerson <sdickers@redhat.com>
sjd78 added a commit that referenced this pull request May 14, 2024
If the workflow is run from a PR, and the PR includes a change to the
`Dockerfile` or `package-lock.json`, then run image builds for all of
our target platforms.

The images are built but not pushed to any repository.

We want to be reasonably sure that any major build file changes will not
cause the image-build-and-push on PR merge workflow to break. Doing the
image build here should reveal most problems much earlier. For example,
a npm version update in the build container could break github action
`nofiles` or network access capabilities for the npm install.

See #1742, #1746, and #1781 for some other examples of when this check
could have caught issues before a PR merge.

Supports: #1883

Signed-off-by: Scott J Dickerson <sdickers@redhat.com>
sjd78 added a commit to sjd78/tackle2-ui that referenced this pull request May 15, 2024
…ange (konveyor#1907)

If the workflow is run from a PR, and the PR includes a change to the
`Dockerfile` or `package-lock.json`, then run image builds for all of
our target platforms.

The images are built but not pushed to any repository.

We want to be reasonably sure that any major build file changes will not
cause the image-build-and-push on PR merge workflow to break. Doing the
image build here should reveal most problems much earlier. For example,
a npm version update in the build container could break github action
`nofiles` or network access capabilities for the npm install.

See konveyor#1742, konveyor#1746, and konveyor#1781 for some other examples of when this check
could have caught issues before a PR merge.

Supports: konveyor#1883
Backport-of: konveyor#1907

Signed-off-by: Scott J Dickerson <sdickers@redhat.com>
sjd78 added a commit to sjd78/tackle2-ui that referenced this pull request May 15, 2024
…ange (konveyor#1907)

If the workflow is run from a PR, and the PR includes a change to the
`Dockerfile` or `package-lock.json`, then run image builds for all of
our target platforms.

The images are built but not pushed to any repository.

We want to be reasonably sure that any major build file changes will not
cause the image-build-and-push on PR merge workflow to break. Doing the
image build here should reveal most problems much earlier. For example,
a npm version update in the build container could break github action
`nofiles` or network access capabilities for the npm install.

See konveyor#1742, konveyor#1746, and konveyor#1781 for some other examples of when this check
could have caught issues before a PR merge.

Supports: konveyor#1883
Backport-of: konveyor#1907

Note: build architectures updated to match the settings on the
      backport target branch

Signed-off-by: Scott J Dickerson <sdickers@redhat.com>
sjd78 added a commit that referenced this pull request May 15, 2024
…ange (#1907) (#1914)

If the workflow is run from a PR, and the PR includes a change to the
`Dockerfile` or `package-lock.json`, then run image builds for all of
our target platforms.

The images are built but not pushed to any repository.

We want to be reasonably sure that any major build file changes will not
cause the image-build-and-push on PR merge workflow to break. Doing the
image build here should reveal most problems much earlier. For example,
a npm version update in the build container could break github action
`nofiles` or network access capabilities for the npm install.

See #1742, #1746, and #1781 for some other examples of when this check
could have caught issues before a PR merge.

Supports: #1883
Backport-of: #1907

Signed-off-by: Scott J Dickerson <sdickers@redhat.com>
sjd78 added a commit that referenced this pull request May 15, 2024
…ange (#1907) (#1915)

If the workflow is run from a PR, and the PR includes a change to the
`Dockerfile` or `package-lock.json`, then run image builds for all of
our target platforms.

The images are built but not pushed to any repository.

We want to be reasonably sure that any major build file changes will not
cause the image-build-and-push on PR merge workflow to break. Doing the
image build here should reveal most problems much earlier. For example,
a npm version update in the build container could break github action
`nofiles` or network access capabilities for the npm install.

See #1742, #1746, and #1781 for some other examples of when this check
could have caught issues before a PR merge.

Supports: #1883
Backport-of: #1907

Note: build architectures updated to match the settings on the backport
target branch

Signed-off-by: Scott J Dickerson <sdickers@redhat.com>
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.

2 participants