Seems there are some errors in the code this time. - #12
Merged
Conversation
Contributor
Author
|
I corrected the folder, but it shows all checks have failed, do you have any idea what's the problem? I will try fix it after class. @sam0227 |
| #include<iostream> | ||
| public class JinggangHelloWorld{ | ||
| public static void main(String[] args){ | ||
| cout << "Hello World!" << endl; |
Contributor
There was a problem hiding this comment.
Please write Java code instead of C style code. Also try compile it before commit. @diaojinggang
Contributor
There was a problem hiding this comment.
Also what's the "textdb/textdb-sandbox/.DS_Store" file? Remove it?
Contributor
There was a problem hiding this comment.
@diaojinggang Please remove the .DS_Store file as well. Thanks for pointing it out @chenlica
Contributor
There was a problem hiding this comment.
@chenlica @diaojinggang @sam0227 .DS_Store is a Mac specific attributes file that is generated by Finder in the Mac environment to store parameters such as order of files in a directory, etc. A convenient way to ensure this don't show up is to add it to a .gitignore file?
Contributor
There was a problem hiding this comment.
@kishore-narendran Some students are not using Mac, and I prefer not to include platform-dependent files. Can we remove it?
Contributor
There was a problem hiding this comment.
@chenlica By adding .DS_Store to the .gitignore file, it will ensure that Git does not add the file to the repository ever, so we will never find it appearing here ever again.
Contributor
There was a problem hiding this comment.
@kishore-narendran OK. Please create a new PR for this minor change, and add me and @JavierJia as reviewers.
Contributor
Author
|
@kishore-narendran I think if I modify the .gitignore file in my branch, it will conflict with master and forbid me to merge. I delete all .DS_Store using this command find . -name .DS_Store -print0 | xargs -0 git rm -f --ignore-unmatchOh, .gitignore in the master has already been modified by you. Never mind. I correct the code now. So should I merge to the master branch? @sam0227 |
Yicong-Huang
added a commit
that referenced
this pull request
May 1, 2026
### What changes were proposed in this PR? Add a release-branch backport automation driven by `release/*` labels on PRs. A PR labelled with `release/<branch>` triggers two workflows: - **Pre-merge** (Build): a `backport` matrix job per labeled target cherry-picks the PR's commits as one squashed change onto a copy of that release branch and runs the full build/test stack on the result, so cherry-pick conflicts and target-branch incompatibilities surface before merge. - **Post-merge** (Direct Backport Push, fires on push to `main`): looks up the merged PR's `release/*` labels, confirms the corresponding pre-merge backport job was green, then cherry-picks the squash-merge commit onto each release branch. The release-branch commit reuses the PR title and description, with a `(cherry picked from commit ...)` trailer. Targets whose pre-merge backport failed are skipped. Adding or removing a `release/*` label on an open PR re-runs the Build with the updated target set; removing a label also cancels the obsolete backport check entries so the PR's check list stays clean. `CONTRIBUTING.md` documents the workflow. ### Any related issues, documentation, discussions? Closes #4580 ### How was this PR tested? End-to-end on a fork (`Yicong-Huang/texera`) with three scenarios. Each test PR was opened against fork `main`, labelled with a `release/*` target, then squash-merged to fire the post-merge workflow. | # | Scenario | Test PR | Backport CI (Build run) | Direct Backport Push | Result | |---|---|---|---|---|---| | 1 | Basic end-to-end | [#10](Yicong-Huang#10) | [run 25209303859](https://github.com/Yicong-Huang/texera/actions/runs/25209303859) ✓ | [run 25209764556](https://github.com/Yicong-Huang/texera/actions/runs/25209764556) ✓ | `release/full-test-2` got cherry-pick [`796160d509`](Yicong-Huang@796160d509) | | 2 | Target behind `main`, clean cherry-pick | [#11](Yicong-Huang#11) | [run 25209304452](https://github.com/Yicong-Huang/texera/actions/runs/25209304452) ✓ | [run 25209768643](https://github.com/Yicong-Huang/texera/actions/runs/25209768643) ✓ | `release/behind-clean` got cherry-pick [`654aac58c0`](Yicong-Huang@654aac58c0) | | 3 | Target behind `main`, add/add conflict | [#12](Yicong-Huang#12) | [run 25209305548](https://github.com/Yicong-Huang/texera/actions/runs/25209305548) ✗ (expected) | [run 25209769952](https://github.com/Yicong-Huang/texera/actions/runs/25209769952) ✓ (target skipped) | `release/conflict-addadd` unchanged | ### Was this PR authored or co-authored using generative AI tooling? Generated-by: Codex GPT-5
github-actions Bot
added a commit
that referenced
this pull request
May 1, 2026
### What changes were proposed in this PR? Add a release-branch backport automation driven by `release/*` labels on PRs. A PR labelled with `release/<branch>` triggers two workflows: - **Pre-merge** (Build): a `backport` matrix job per labeled target cherry-picks the PR's commits as one squashed change onto a copy of that release branch and runs the full build/test stack on the result, so cherry-pick conflicts and target-branch incompatibilities surface before merge. - **Post-merge** (Direct Backport Push, fires on push to `main`): looks up the merged PR's `release/*` labels, confirms the corresponding pre-merge backport job was green, then cherry-picks the squash-merge commit onto each release branch. The release-branch commit reuses the PR title and description, with a `(cherry picked from commit ...)` trailer. Targets whose pre-merge backport failed are skipped. Adding or removing a `release/*` label on an open PR re-runs the Build with the updated target set; removing a label also cancels the obsolete backport check entries so the PR's check list stays clean. `CONTRIBUTING.md` documents the workflow. ### Any related issues, documentation, discussions? Closes #4580 ### How was this PR tested? End-to-end on a fork (`Yicong-Huang/texera`) with three scenarios. Each test PR was opened against fork `main`, labelled with a `release/*` target, then squash-merged to fire the post-merge workflow. | # | Scenario | Test PR | Backport CI (Build run) | Direct Backport Push | Result | |---|---|---|---|---|---| | 1 | Basic end-to-end | [#10](Yicong-Huang#10) | [run 25209303859](https://github.com/Yicong-Huang/texera/actions/runs/25209303859) ✓ | [run 25209764556](https://github.com/Yicong-Huang/texera/actions/runs/25209764556) ✓ | `release/full-test-2` got cherry-pick [`796160d509`](Yicong-Huang@796160d509) | | 2 | Target behind `main`, clean cherry-pick | [#11](Yicong-Huang#11) | [run 25209304452](https://github.com/Yicong-Huang/texera/actions/runs/25209304452) ✓ | [run 25209768643](https://github.com/Yicong-Huang/texera/actions/runs/25209768643) ✓ | `release/behind-clean` got cherry-pick [`654aac58c0`](Yicong-Huang@654aac58c0) | | 3 | Target behind `main`, add/add conflict | [#12](Yicong-Huang#12) | [run 25209305548](https://github.com/Yicong-Huang/texera/actions/runs/25209305548) ✗ (expected) | [run 25209769952](https://github.com/Yicong-Huang/texera/actions/runs/25209769952) ✓ (target skipped) | `release/conflict-addadd` unchanged | ### Was this PR authored or co-authored using generative AI tooling? Generated-by: Codex GPT-5 (cherry picked from commit addcb4e)
SarahAsad23
pushed a commit
to SarahAsad23/texera
that referenced
this pull request
May 4, 2026
### What changes were proposed in this PR? Add a release-branch backport automation driven by `release/*` labels on PRs. A PR labelled with `release/<branch>` triggers two workflows: - **Pre-merge** (Build): a `backport` matrix job per labeled target cherry-picks the PR's commits as one squashed change onto a copy of that release branch and runs the full build/test stack on the result, so cherry-pick conflicts and target-branch incompatibilities surface before merge. - **Post-merge** (Direct Backport Push, fires on push to `main`): looks up the merged PR's `release/*` labels, confirms the corresponding pre-merge backport job was green, then cherry-picks the squash-merge commit onto each release branch. The release-branch commit reuses the PR title and description, with a `(cherry picked from commit ...)` trailer. Targets whose pre-merge backport failed are skipped. Adding or removing a `release/*` label on an open PR re-runs the Build with the updated target set; removing a label also cancels the obsolete backport check entries so the PR's check list stays clean. `CONTRIBUTING.md` documents the workflow. ### Any related issues, documentation, discussions? Closes apache#4580 ### How was this PR tested? End-to-end on a fork (`Yicong-Huang/texera`) with three scenarios. Each test PR was opened against fork `main`, labelled with a `release/*` target, then squash-merged to fire the post-merge workflow. | # | Scenario | Test PR | Backport CI (Build run) | Direct Backport Push | Result | |---|---|---|---|---|---| | 1 | Basic end-to-end | [apache#10](Yicong-Huang#10) | [run 25209303859](https://github.com/Yicong-Huang/texera/actions/runs/25209303859) ✓ | [run 25209764556](https://github.com/Yicong-Huang/texera/actions/runs/25209764556) ✓ | `release/full-test-2` got cherry-pick [`796160d509`](Yicong-Huang@796160d509) | | 2 | Target behind `main`, clean cherry-pick | [apache#11](Yicong-Huang#11) | [run 25209304452](https://github.com/Yicong-Huang/texera/actions/runs/25209304452) ✓ | [run 25209768643](https://github.com/Yicong-Huang/texera/actions/runs/25209768643) ✓ | `release/behind-clean` got cherry-pick [`654aac58c0`](Yicong-Huang@654aac58c0) | | 3 | Target behind `main`, add/add conflict | [apache#12](Yicong-Huang#12) | [run 25209305548](https://github.com/Yicong-Huang/texera/actions/runs/25209305548) ✗ (expected) | [run 25209769952](https://github.com/Yicong-Huang/texera/actions/runs/25209769952) ✓ (target skipped) | `release/conflict-addadd` unchanged | ### Was this PR authored or co-authored using generative AI tooling? Generated-by: Codex GPT-5
aicam
referenced
this pull request
in aicam/texera
Jun 5, 2026
feat(frontend): advanced settings for computing-unit creation
This was referenced Jun 6, 2026
This was referenced Jun 9, 2026
yangzhang75
pushed a commit
to yangzhang75/texera
that referenced
this pull request
Jun 22, 2026
### What changes were proposed in this PR? Add a release-branch backport automation driven by `release/*` labels on PRs. A PR labelled with `release/<branch>` triggers two workflows: - **Pre-merge** (Build): a `backport` matrix job per labeled target cherry-picks the PR's commits as one squashed change onto a copy of that release branch and runs the full build/test stack on the result, so cherry-pick conflicts and target-branch incompatibilities surface before merge. - **Post-merge** (Direct Backport Push, fires on push to `main`): looks up the merged PR's `release/*` labels, confirms the corresponding pre-merge backport job was green, then cherry-picks the squash-merge commit onto each release branch. The release-branch commit reuses the PR title and description, with a `(cherry picked from commit ...)` trailer. Targets whose pre-merge backport failed are skipped. Adding or removing a `release/*` label on an open PR re-runs the Build with the updated target set; removing a label also cancels the obsolete backport check entries so the PR's check list stays clean. `CONTRIBUTING.md` documents the workflow. ### Any related issues, documentation, discussions? Closes apache#4580 ### How was this PR tested? End-to-end on a fork (`Yicong-Huang/texera`) with three scenarios. Each test PR was opened against fork `main`, labelled with a `release/*` target, then squash-merged to fire the post-merge workflow. | # | Scenario | Test PR | Backport CI (Build run) | Direct Backport Push | Result | |---|---|---|---|---|---| | 1 | Basic end-to-end | [apache#10](Yicong-Huang#10) | [run 25209303859](https://github.com/Yicong-Huang/texera/actions/runs/25209303859) ✓ | [run 25209764556](https://github.com/Yicong-Huang/texera/actions/runs/25209764556) ✓ | `release/full-test-2` got cherry-pick [`796160d509`](Yicong-Huang@796160d509) | | 2 | Target behind `main`, clean cherry-pick | [apache#11](Yicong-Huang#11) | [run 25209304452](https://github.com/Yicong-Huang/texera/actions/runs/25209304452) ✓ | [run 25209768643](https://github.com/Yicong-Huang/texera/actions/runs/25209768643) ✓ | `release/behind-clean` got cherry-pick [`654aac58c0`](Yicong-Huang@654aac58c0) | | 3 | Target behind `main`, add/add conflict | [apache#12](Yicong-Huang#12) | [run 25209305548](https://github.com/Yicong-Huang/texera/actions/runs/25209305548) ✗ (expected) | [run 25209769952](https://github.com/Yicong-Huang/texera/actions/runs/25209769952) ✓ (target skipped) | `release/conflict-addadd` unchanged | ### Was this PR authored or co-authored using generative AI tooling? Generated-by: Codex GPT-5
renovate-bot
pushed a commit
to renovate-bot/apache-_-texera
that referenced
this pull request
Aug 8, 2026
…epts (apache#7257) ### What changes were proposed in this PR? Three colour settings — Line Chart's Line Color, Continuous Error Bands' Fill Color, and Figure Factory Table's Font Color — were plain strings whose only statement of what is legal lived in a description. Each now declares a `pattern` mirroring `ColorValidator` in plotly's `_plotly_utils/basevalidators.py`: 3- or 6-digit hex, an `rgb`/`rgba`/`hsl`/`hsla`/`hsv`/`hsva` call, a `var(--…)` variable, or a colour name. Empty stays legal, since every one of these paths omits the colour argument when the field is blank. Two details are deliberate. Letters are matched through character classes rather than an inline `(?i)`, because the browser compiles the pattern with `new RegExp`. And `\s*` sits between every element, because plotly strips spaces before matching and really does accept `#ff ffff`; rejecting those would make the field stricter than the library it feeds. The colour-name branch is lexical, so a misspelling still reaches plotly — matching exactly would mean copying plotly's 148 CSS names into the annotation. ### Why are the changes needed? Nothing inspected the value before the run, so a mistyped colour aborted a workflow inside plotly with an error naming a plotly property rather than the field the user filled in: `ValueError: Invalid value of type 'builtins.str' received for the 'color' property of scatter.line`. ### Any related issues, documentation, discussions? Closes apache#7252 ### How was this PR tested? `scalafmtCheckAll`, `scalafixAll --check`, and the three operators' descriptor specs. The new `ColorPatternSpec` covers the pattern: it reads it back out of the generated schema for each of the four fields that carry it, then tests sixteen values — ten accepted, one per branch, and six rejected near-misses — as one test per case, 69 in total. The same sixteen were checked under `new RegExp` and against plotly itself, which agrees on every one except a misspelled colour name, as noted above. ### Does this PR introduce any user-facing change? Yes. The three fields now reject `1`, `apache#12`, `#ggg`, `#ffff`, `rgb(1,2)` and `rgb(-1,2,3)` in the form. Every value that previously produced a chart still does. ### Was this PR authored or co-authored using generative AI tooling? Generated-by: Claude Code (Claude Opus 5) --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
I made some change and now it might contain some error. Please help me point them out. Thanks. @sam0227