-
Notifications
You must be signed in to change notification settings - Fork 72
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
Start turning GitGitGadget into a set of GitHub Actions and workflows #1392
base: main
Are you sure you want to change the base?
Conversation
Signed-off-by: Johannes Schindelin <[email protected]>
Signed-off-by: Johannes Schindelin <[email protected]>
It really needs to be reusable instead of being stuck in the script. In particular since we're about to modify GitGitGadget such that it can be run as a GitHub Action instead. Signed-off-by: Johannes Schindelin <[email protected]>
It was a bit hard for me to follow the code, getting confused by two separate `getConfig()` functions that do different things (the one from `gitgitgadget-config` initializes the default config, the one from `project-config` gets a singleton that might still be uninitialized). Let's unconfuse things by making the config a non-optional parameter of the constructor. Note: This commit is only concerned with the CIHelper class, because we will use it from light-weight GitHub Actions in the future. The rest of the code really needs to use the singleton up until the time when we'll get around to The Big Refactor. Signed-off-by: Johannes Schindelin <[email protected]>
Preparing for turning GitGitGadget into a bunch of GitHub Actions, we install `ncc` which will allow us to bundle a minimal set of Javascript files and publish that via a tag. The idea is to run `ncc build -s -m lib/ci-helper.ts -o dist/` to obtain a minimized `dist/index.js` that has no additional dependencies, and then have subdirectories (e.g. `update-prs/`) with the individual `action.yml` and `index.js` that starts with the following line const { CIHelper } = require('../dist/index.js') This will allow us to publish a single tag that backs the various functionalities as different GitHub Actions. Signed-off-by: Johannes Schindelin <[email protected]>
The idea is to move the `set()` function to CIHelper, to make it reusable. Before that, however, we must make sure that it is generic enough, e.g. by allowing to pass the App's private key as a parameter (instead of expecting it in the environment or in the Git config). Signed-off-by: Johannes Schindelin <[email protected]>
This will make it possible to use it from somewhere else than the `misc-helper.ts` script. Signed-off-by: Johannes Schindelin <[email protected]>
There were a few linting issues I had missed, so I added another reaction (via https://github.com/gitgitgadget/gitgitgadget/actions/runs/5916258877). |
The plan is to turn GitGitGadget into a set of GitHub Actions that can be run conveniently from GitHub workflows. To that end, we will add subdirectories (e.g. `init/`, `handle-prs/`, etc) that reflect the individual functionality that is currently called in Azure Pipelines via subcommands of the `misc-helper` script. Those subdirectories will contain the bare minimum required to implement a Javascript Action that calls into the CIHelper class: an `action.yml` file to declare the inputs/outputs, and a minimal `index.js` that consumes the inputs and passes them to the CIHelper. The CIHelper class will be used by the Action via as a single, dependency-free `dist/index.js`, and it will be the only dependency of the Action's `index.js`. In particular, we must not let the Action's minimal `index.js` depend on `@actions/core` because it simply won't be there. So let's add it as a dependency of the CIHelper class and provide a function to allow calling the imported `@actions/core` functions from the Actions' `index.js`. Signed-off-by: Johannes Schindelin <[email protected]>
This will come in handy in GitHub workflows. Signed-off-by: Johannes Schindelin <[email protected]>
The idea is to let `ncc` turn the CIHelper code into a dependency-free `dist/index.js` and then remove all files other than `*/action.yml` and `*/index.js`, commit and tag that. That's the GitHub Action, ready to be used in GitHub workflows. Signed-off-by: Johannes Schindelin <[email protected]>
Signed-off-by: Johannes Schindelin <[email protected]>
Signed-off-by: Johannes Schindelin <[email protected]>
This should add the 'hooray' reaction to dscho/git#29 (comment) (using my fork for testing...). Signed-off-by: Johannes Schindelin <[email protected]>
fyi, I am reviewing this. Just taking some time. |
@webstech no worries! |
This PR will need to be updated using #1473 once that one is merged, to be used in a post-Action of the |
As discussed in #609, let's turn GitGitGadget into a couple of GitHub workflows that call into the actual
gitgitgadget/gitgitgadget
code via GitHub Actions.The idea is to implement all the core logic such that it can be called via CIHelper. This class will then be bundled and minified into
dist/index.js
, a dependency-free, standalone Javascript module. Now, the GitHub Actions will basically be tiny subdirectories that contain anaction.yml
to define the Action andindex.js
to parse the input, call into CIHelper (via thatdist/index.js
) and consume the output (if any) by setting the workflow step's output(s).To avoid wasting bandwidth delivering the Actions, I would like to eventually set up a workflow that auto-deploys
main
: whenever there is a new commit, it should:npm run build-dist
,dist/
and the Actions' subdirectories,v1
branch so that the GitHub workflows can use the Actions via, say,uses: gitgitgadget/gitgitgadget/handle-prs@v1
v1
branch (and themain
branch, which now has a single commit advancing the version at the tip).This PR is currently a draft because it only demonstrates the direction I'd like to go, but leaves the approach up for discussion before putting in the whole work to actually migrate all of GitGitGadget.
Currently only the
init
Action is implemented, which obtains the access tokens.To verify that it all works as intended, I added a commit to add a reaction to dscho/git#29 (comment) (the commit will be dropped before long, of course, it's intention was only to demonstrate that the design works).
Oh, and best of all: the way the Azure Pipelines run GitGitGadget via
misc-helper
will continue working all the way through the migration.