Htcondor comparison

[mtwest2718]

A good faith attempt trying to follow what I know from my own experience and the htcondor docs to fill in the comparison chart. Some of these categories seem explicitly designed to distinguish Flux from its nominal competitors, which makes any apples to apples comparison hard.

[mtwest2718]

I will be happy to try to run down any technical details if you need performance metrics or documentation references to justify my answers in the comparison table.

[mtwest2718]

It's not obvious to me what exactly is causing the build to fail.

[vsoch]

That's for some of the rendered examples, and you would basically need to follow the instructions in the README to do the build locally: https://github.com/flux-framework/flux-docs#setup basically open in VSCode, "Open in DevContainer" and then flux start make html.

If that is too much, don't worry about it - I would be happy to do this on your behalf when the review is done.

[mtwest2718]

I avoid VSCode like the plague. But I presume I should be able to run through the build steps via a set of terminal commands, right?

[vsoch]

Yes you would need to basically run that command from a host or container with Flux. If you'd like to use a container, the .devcontainer Dockerfile https://github.com/flux-framework/flux-docs/blob/master/.devcontainer/Dockerfile should give you the right environment, and you'd want to build it and bind your working directory to /workspace/flux-docs (note that VSCode does this all for you!). Make sure you run the flux start make html inside the container in that root, and commit from the outside.

And no worries if you don't like VSCode, it's been very popular at my institution, and I found it last year and really love it for so many reasons. I was a productive programmer before, but with VSCode I can easily write a few thousand lines of new code in a weekend. Thanks for your contribution! The main Flux devs should be able to take a look when they have some time.

[vsoch]

@mtwest2718 you should be able to rebase locally to fix the CI error now - there was a change in an auto example (likely from a version change) that needed to be made.

[mtwest2718]

@vsoch pulled changes from flux-docs:master into this development branch. I don't see any new autobuild & test checks upon updating the PR. So will assume everything is kosher from that perspective.

[vsoch]

@mtwest2718 you'll want to rebase. The checks have to be approved always by a maintainer:

[mtwest2718]

TBH, I have never used git rebase. Usually just sequence of pull and merge.
How exactly do I fix this workflow issue since I used github.com's merge button to pull in upstream changes?

[vsoch]

I can give instructions for rebasing https://vsoch.github.io/2019/rebasing/ and you might need some extra fu for the merge commit: https://stackoverflow.com/a/47818810. Pinging @grondo if he has other advice!

[grondo]

$ git fetch origin  # assuming origin is this upstream repo
$ git rebase -i origin/master # interactive rebase, delete merge commit in list of commits and save-quit
$ git push -f <your-repo> htcondor_comparison

Github also does seem to have a "rebase" atlernative to the merge button now. The merge button is actually a drop down and one of the choices is rebase. Works great if there are no conflicts.

https://github.blog/changelog/2022-02-03-more-ways-to-keep-your-pull-request-branch-up-to-date/

[vsoch]

Thanks @grondo ! 🙏

[mtwest2718]

I do not see any button that says update branch or rebase in github for this PR.

To github.com:mtwest2718/flux-docs.git
 ! [rejected]        htcondor_comparison -> htcondor_comparison (non-fast-forward)
error: failed to push some refs to 'github.com:mtwest2718/flux-docs.git'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Integrate the remote changes (e.g.
hint: 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

I might just give up on this. Not worth the effort.

[vsoch]

@mtwest2718 when you rebase, you change the git history, so you typically need to push with --force. You can check your changes and use git log to ensure that you are forcing the right content.

TLDR: that message you received is expected with a rebase.